From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 00:09:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B1D8D96; Sun, 16 Nov 2014 00:09:09 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C02619CF; Sun, 16 Nov 2014 00:09:08 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id h15so1605478igd.8 for ; Sat, 15 Nov 2014 16:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UTRQr/tf0YsCgTlhQREygqA8GAnlGAWajO6/oNKfsdc=; b=x6BTH1Gnbg3sszJ/L0wZh1EXbmLpns5Vh0IjE+jWUMB+ED03b9EX+ENmn5DYcZ/Kng /6z2cO6VPDHmbU2tqVspS0CY480RIuQi6ZQqUvwJp+DqP/rlnaEhKQXo0SLckWj5+FEc ykzctkMI4DMjvj2vL/flJ6N8/uSt/RqtDNzR8aPjMeWPWsXWnY+H9LUm2lhDHRbu8H1O sBqTAcEHKCvD7fVSTAMJAIEhQjyXwGdJfCz+RT1eYrt6966xDWiLQYVhOZ4Dmfn+jJFe atGCid2OrpiSa+/5T7GZ1fFHoet9o4j29AfNIqemLFaPRq0s543wDXJYhddaLqa5tS5F EFrQ== MIME-Version: 1.0 X-Received: by 10.42.100.14 with SMTP id y14mr4449icn.64.1416096548159; Sat, 15 Nov 2014 16:09:08 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.7.169 with HTTP; Sat, 15 Nov 2014 16:09:08 -0800 (PST) In-Reply-To: References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> Date: Sat, 15 Nov 2014 16:09:08 -0800 X-Google-Sender-Auth: U0qHsL_8trrute8fh7HMxrkkU9Q Message-ID: Subject: Re: best overall upgrade from 8.x? From: Kevin Oberman To: Michael Ross Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List , Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 00:09:09 -0000 On Sat, Nov 15, 2014 at 9:38 AM, Michael Ross wrote: > On Sat, 15 Nov 2014 16:20:49 +0100, Dimitry Andric > wrote: > > On 15 Nov 2014, at 13:53, Adrian Wontroba wrote: >> >>> >>> On Sat, Nov 15, 2014 at 12:44:33PM +0100, Andrea Venturoli wrote: >>> >>>> On 11/15/14 05:48, Kevin Oberman wrote: >>>> >>>>> I'd wait a month or so and, if no problems that might impact you pop >>>>> up, >>>>> I'd go with 10.1 >>>>> >>>> Uh... is direct upgrade (using sources) possible from 8.4 to 10.1? >>>> No need to step through 9.x? >>>> >>> >>> Even the move from 9.2 (a near year old 9/stable) to 10.1 (stable/10 as >>> of about 3 weeks ago) is slightly problematic. >>> >>> Following the normal upgrade procedure of installkernel and then >>> rebooting with the userland untouched runs into a problem whereby >>> rc.conf falls apart with a shower of eval errors, no networking, ... >>> >>> I do not know the cause. >>> >> >> I almost certainly know the cause: you are supposed to reboot into >> single user mode after installkernel. A regular boot to full multi user >> mode may or may not work, depending on numerous unpredictable >> circumstances. :-) >> >> > If you follow the handbook, > you are not supposed to reboot at all after installkernel. > I think it was advised once, but it does no longer say so, > it just says "drop to single user". > > Well, it still says "[single user] also minimizes any problems from > running the old world on a new kernel." which you don't actually do if you > follow the instructions. > I'm disturbed that this change was made. It's in invitation to an unlikely, but very real disaster. It has not been changed in UPDATING and I strongly feel that it should be reverted in the Handbook. The problem with failing to reboot to single user (as opposed to just dropping to single-user) is that you are installing (and running) the new world while still running the old kernel. This, of itself could make the system unstable until it is rebooted, but the more serious issue is that you have an untested kernel that will be used on the next reboot. If it fails to boot, you are in a deep hole as you already are running a new world. You could just boot the old kernel and figure out what went wrong at your leisure. Instead you are stuck with a new world and an old kernel at best. That may or may not give you a usable system and dropping back to the old world is not trivial. It can leave you down for a while as you recover. I speak from pained experience having been bitten by this some years ago. It took quite some effort to recover. I just happened to buildkernel at a bad time when it was broken. It was fixed shortly, but I had no working network, so could not get the fix or even pull down a CD image with an old userland that would work. It would be a bit easier to deal with today as I could use another system to pull down a memory stick system that could have greatly simplified the fix, but there is a good reason to be sure that the new kernel builds BEFORE updating userland. I think recommending this is a very bad idea. Going back the the original issue: > cd /usr/src > mergemaster -p So far, so good. > make installkernel > make installworld OK. Where were the buildworld and buildkernel? Both should have come after the "mergemaster -p" though there has never been a case where "mergemaster -p" has been required before buildworld. Still, there might be some day. The man page states that it should precede the buildworld, too. "-p Pre-buildworld mode. Compares only files known to be essential to the success of {build|install}world, including /etc/make.conf." > mergemaster > shutdown -r now I agree that this will usually work fine and I have done it, but I have always done the same update on a local system first, just in case, and I understand that I may shoot my system in the foot and that may require an extended down-time. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 01:09:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5826CBA for ; Sun, 16 Nov 2014 01:09:32 +0000 (UTC) Received: from o1.l99.sendgrid.net (o1.l99.sendgrid.net [198.37.153.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AD01EBE for ; Sun, 16 Nov 2014 01:09:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:content-type:content-transfer-encoding; s=smtpapi; bh=vDY3veT+BuzYG5d+S1tHHpE+L9w=; b=KoJOqzzVgHwQ3aMHUp VO4PvkxqN3Isc5CIp84IEHOF9NBSXbO6KpXdiBEbxNBb+TxZ+DOfzVXXLvWgKubf JYdKW0AAozINTTAIAkS3WNVmGCEv2G+WjaDF1O4SXbvlJVwtMkko0gEzSncfwtWW 0dOl9a24/ildVbmS2qqKOt8PA= Received: by filter0046p1mdw1.sendgrid.net with SMTP id filter0046p1mdw1.13403.5467F94913 2014-11-16 01:09:29.971722336 +0000 UTC Received: from mail.tarsnap.com (unknown [10.100.60.108]) by ismtpd-013 (SG) with ESMTP id 149b625c8b9.7710.7c46c for ; Sun, 16 Nov 2014 01:09:29 +0000 (UTC) Received: (qmail 34787 invoked from network); 16 Nov 2014 01:09:29 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 16 Nov 2014 01:09:29 -0000 Received: (qmail 85639 invoked from network); 16 Nov 2014 01:08:11 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 16 Nov 2014 01:08:11 -0000 Message-ID: <5467F8FB.1010300@freebsd.org> Date: Sat, 15 Nov 2014 17:08:11 -0800 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: freebsd-update from 10.1-RC3 fixed Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SG-EID: 5qVSvszVOIE6PbdhSmXigGB+QElqqXSFvopX9r8bq1BtIb0lZKHUs6+Doh/LYqCu/x7991DLrSNWae XIdX2NMPFHxDQtpKw+UFKDzCL5W9XUdtTbksKLYFNGP3II8s1/PLHqUK0UyE5HQZpbjFJ1RzWrofOx HrqMx6XHhrPTNGJPog+ecprIQ0ZxczVY8xhp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 01:09:32 -0000 Hi all, The problems with running freebsd-update on 10.1-RC3 (including using freebsd-update to upgrade to -RC4 or -RELEASE) should now be fixed. The problem was due to some files being missing from freebsd-update mirrors and resulted from -RC3 going out at the same time as patches were being built for a set of security advisories (SA-14:20 through 14:23). I know this glitch has been discussed in a large number of places, and I'm sure there are people who have been affected by this who are not subscribed to -stable, so please relay this message to the appropriate fora where you see this being discussed. Thanks, -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 02:19:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FE78EA2 for ; Sun, 16 Nov 2014 02:19:59 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAF626D0 for ; Sun, 16 Nov 2014 02:19:58 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:2580:674:21c:c0ff:fe7f:96ee]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 30C0C2D4FB4; Sun, 16 Nov 2014 02:19:57 +0000 (UTC) Received: from [IPv6:2601:7:2580:674:baca:3aff:fe83:bd29] (ivy.libssl.so [IPv6:2601:7:2580:674:baca:3aff:fe83:bd29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chombo.houseloki.net (Postfix) with ESMTPSA id E29019F0; Sat, 15 Nov 2014 18:19:54 -0800 (PST) Message-ID: <546809C7.70706@bluerosetech.com> Date: Sat, 15 Nov 2014 18:19:51 -0800 From: Darren Pilgrim Reply-To: FreeBSD-STABLE Mailing List User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: best overall upgrade from 8.x? References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 02:19:59 -0000 On 11/15/2014 4:09 PM, Kevin Oberman wrote: > OK. Where were the buildworld and buildkernel? Both should have come after > the "mergemaster -p" though there has never been a case where "mergemaster > -p" has been required before buildworld. ISTR the splitting of UIDs for sendmail required running mergemaster -p before buildworld. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 06:17:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE9DC97D for ; Sun, 16 Nov 2014 06:17:16 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1753DD4 for ; Sun, 16 Nov 2014 06:17:16 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id r10so3635478igi.0 for ; Sat, 15 Nov 2014 22:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Iygjn0jG5kpxJSIVe7fmaXY0TUg10p/kXX+BJIIhy1s=; b=NZmkreKKkwNjk/t65c9kVKdJv+h8z6m0K0gYIveuQBsSuiCFsmlNTI4108iayUZa+q cHBdnUQzRRf8GReGWD3DJhzdmPwhqnktIOLH3s2wGCZuQTKJYOgQaAlXNMAOmNGNCqY6 1XqYfJR8C3U54OQkOoZ3rqrblszSo88dn90kPDIq5fW0TOLtT7pWaRqCWvI5cV2Fndyx jjLaOyuKjNNv/xqKx4+3TbTdJ9WGbmhNX57iei8SA/vbfrj0DeY8C7jwf3AjkLWiBALn POmAQYCjsEJLI5e9dENjgPBvMysGOs5MVCZhECF/s6wRmyIbUa1zoNDErKMAZuilBwXQ zYIg== MIME-Version: 1.0 X-Received: by 10.50.43.135 with SMTP id w7mr17525942igl.0.1416118636191; Sat, 15 Nov 2014 22:17:16 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.7.169 with HTTP; Sat, 15 Nov 2014 22:17:16 -0800 (PST) In-Reply-To: <546809C7.70706@bluerosetech.com> References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> <546809C7.70706@bluerosetech.com> Date: Sat, 15 Nov 2014 22:17:16 -0800 X-Google-Sender-Auth: swsckfN_e563L2fazZ-MIIWYzZ0 Message-ID: Subject: Re: best overall upgrade from 8.x? From: Kevin Oberman To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:17:17 -0000 Darren, I will need to check the archives, but I believe that this only required running it before buildkernel, but you may be right. R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com On Sat, Nov 15, 2014 at 6:19 PM, Darren Pilgrim < list_freebsd@bluerosetech.com> wrote: > On 11/15/2014 4:09 PM, Kevin Oberman wrote: > >> OK. Where were the buildworld and buildkernel? Both should have come after >> the "mergemaster -p" though there has never been a case where "mergemaster >> -p" has been required before buildworld. >> > > ISTR the splitting of UIDs for sendmail required running mergemaster -p > before buildworld. > > From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 06:29:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EB92DC4 for ; Sun, 16 Nov 2014 06:29:03 +0000 (UTC) Received: from nm2-vm10.bullet.mail.sg3.yahoo.com (nm2-vm10.bullet.mail.sg3.yahoo.com [106.10.148.99]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E146EDC for ; Sun, 16 Nov 2014 06:29:02 +0000 (UTC) Received: from [106.10.166.121] by nm2.bullet.mail.sg3.yahoo.com with NNFMP; 16 Nov 2014 06:26:04 -0000 Received: from [106.10.150.29] by tm10.bullet.mail.sg3.yahoo.com with NNFMP; 16 Nov 2014 06:26:04 -0000 Received: from [127.0.0.1] by omp1030.mail.sg3.yahoo.com with NNFMP; 16 Nov 2014 06:26:04 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 353781.56547.bm@omp1030.mail.sg3.yahoo.com Received: (qmail 14519 invoked by uid 60001); 16 Nov 2014 06:26:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1416119164; bh=oTrwzkqomjYqz6DUQFOCWsN2ZMfhCvl+HFFahE39JFs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZCI8nA7qsizbkFG0tnWG3Q6pDLlyszZo5gLMMHDRsxyNSyS+IP04R76bniVh6RKv+BJuwqe8o/4sfo9q9KGcKv1NSipDdjRETUlFZiHA/MZ2FOALkOpk5Ulqhhgk3zn7vRuHwYR+ZYTcbIwmKQ3cxf16RQdgmPi1DT3hLMXU7m4= X-YMail-OSG: JV23kKUVM1kmTJ3mbsyjbxUWLQvGLlbBzi5OJCLgmLV5lg6 HYNdfS5C9ntqDSd9rR0rbLI_gOau3TDTukydtoT2XkH8.ESPiH5IuOHXXK84 DPeMrdxSFMjcZZNRq_2Tw531jVPI8.0p8nw.pOdeLeQswnfcx07gX0F.aage EtG_c9BJ694jaGt12bWxE0VDnclQ4lzOw.0gvCZGw73VA5az7mBpb.Ek_sBR 2ol6gta748EANCIwYccxbdZWKC6po4iP.AcZFsx61Gvbft3nPGnXXW6CoiMt l2V5cm2qYRn82yACTxDGe1jkzVC53EK5nZCrC_D396HkSY.N4srMKwFMl9Tq DFY5isehwdTOjRcdRHBf9tSoKiRfwQ5KVUwBQrPADlNUY_zxGXWNIbDNx8ET 8F1K0qgJYUWZkbjUbWx0Nn4PZIn1dDv7SaJ_z1amaN6VPrQCYYR.QZ4hLFL5 83WCTRWLOC_DcfmMkXdET7jIVP42SZeJayDIPJ5AoCu26LJK5YtOfXJC14nZ 1uTNHoeq9IK_VvUltGcDW_Nh0B7lXXfgCHFS9eVwUPvtAn.ahIn0sju4xVYO TCk4uHpdR5ODew9D1cTcdim44LZuKbWjG2cGK7yiCK13zU8TbygYjtFQs1iY O5wCk Received: from [122.167.78.219] by web190705.mail.sg3.yahoo.com via HTTP; Sun, 16 Nov 2014 14:26:04 SGT X-Rocket-MIMEInfo: 002.001, PiBPbiBTdW5kYXksIDE2IE5vdmVtYmVyIDIwMTQgMToxMSBBTSwgS2V2aW4gT2Jlcm1hbiA8cmtvYmVybWFuQGdtYWlsLmNvbT4gd3JvdGU6Cj4gT24gU2F0LCBOb3YgMTUsIDIwMTQgYXQgNzozMiBBTSwgTWFzb29tIFNoYWlraCB2aWEgZnJlZWJzZC1zdGFibGUgPAo.IAo.IGZyZWVic2Qtc3RhYmxlQGZyZWVic2Qub3JnPiB3cm90ZToKPiAKPiA.IEkgaW5zdGFsbGVkIDEwLjEtUkMzIHZpYSBVU0IgaW1hZ2Ugb24gbXkgbGFwdG9wLCBpbiBiaWQgdG8gdXBncmFkZQo.ID4gMTAuMS1SRUxFQVNFIEkgcmFuCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <1416065576.26947.YahooMailNeo@web190701.mail.sg3.yahoo.com> Message-ID: <1416119164.65186.YahooMailNeo@web190705.mail.sg3.yahoo.com> Date: Sun, 16 Nov 2014 14:26:04 +0800 From: Masoom Shaikh Reply-To: Masoom Shaikh Subject: Re: Upgrade from 10.1-RC3 to 10.1-RELEASE using freebsd-update To: Kevin Oberman In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:29:03 -0000 > On Sunday, 16 November 2014 1:11 AM, Kevin Oberman = wrote:=0A> On Sat, Nov 15, 2014 at 7:32 AM, Masoom Shaikh via freebsd-stabl= e <=0A> =0A> freebsd-stable@freebsd.org> wrote:=0A> =0A> > I installed 10.1= -RC3 via USB image on my laptop, in bid to upgrade=0A> > 10.1-RELEASE I ran= =0A> > #freebsd-update fetch -r 10.1-RELEASE=0A> > it fails saying=0A> > Lo= oking up update.FreeBSD.org mirrors... 5 mirrors found.=0A> > Fetching meta= data signature for 10.1-RC3 from update5.freebsd.org... done.=0A> > Fetchin= g metadata index... fetch:=0A> > http://update5.freebsd.org/10.1-RC3/amd64/= t/c8fafcc79d7cc092c7782f4f1a29a777d751294183c8f2cb9daf940ba0525d96:=0A> > N= ot Found=0A> > failed.=0A> >=0A> > this topic has already been discussed he= re=0A> >=0A> > https://lists.freebsd.org/pipermail/freebsd-stable/2014-Nove= mber/080954.html=0A> > and=0A> >=0A> >=0A> > https://forums.freebsd.org/thr= eads/freebsd-update-r-10-1-rc4-upgrade-fails.48835/=0A> >=0A> >=0A> > solut= ion is actually mentioned in forums threads=0A> > what it suggest is=0A> > = #freebsd-update rollback=0A> > #reboot=0A> > #freebsd-update fetch=0A> > #f= reebsd-update upgrade -r 10.1-RC4=0A> > #freebsd-upgrade install=0A> > #reb= oot=0A> > #freebsd-upgrade install=0A> >=0A> > for me rollback fails saying= =0A> > No rollback directory found.=0A> > maybe because I did not install R= C3 via freebsd-update, nonetheless any=0A> > fix as yet?=0A> =0A> > _______= ________________________________________=0A> > freebsd-stable@freebsd.org m= ailing list=0A> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable= =0A> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd= .org"=0A> >=0A> =0A> You're using the wrong command to freebsd-update.=0A> = # freebsd-update upgrade -r 10.1-RELEASE=0A> =0A> "fetch" is appropriate to= updating for patches to the release you are=0A> currently running.=0Athat = oversight while drafting note. I did use 'upgrade'=0A=0A> =0A> Since you in= stalled from a USB distribution, there is no rollback. The=0A> rollback dat= a is created by freebsd-update.=0Ayes, this was my guess as well.=0A=0A> = =0A> Also, I suspect you entered the data above from memory as freebsd-upgr= ade=0A> is not a command in base freebsd.=0Anopes, this is an laptop with F= reeBSD-10.1-RC3 installed and /usr/sbin/freebsd-update is in base.=0A=0Amy = problem has been solved, this was an server issues.=0Ahttps://lists.freebsd= .org/pipermail/freebsd-stable/2014-November/080996.html=0A=0A> --=0A> R. Ke= vin Oberman, Network Engineer, Retired=0A> E-mail: rkoberman@gmail.com=0A> = _______________________________________________=0A> freebsd-stable@freebsd.= org mailing list=0A> http://lists.freebsd.org/mailman/listinfo/freebsd-stab= le=0A> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd= .org=0A> " From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 06:39:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DDBE15D for ; Sun, 16 Nov 2014 06:39:32 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07040FBA for ; Sun, 16 Nov 2014 06:39:32 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so717123ieb.40 for ; Sat, 15 Nov 2014 22:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=9KaYAy4KYlyQvVbOQZz8iCrsuxjZRXCZtbQKKkrLV1o=; b=UMWiSW9aAcqOwFd9ToBhznmssDzP9NP3FjY5WZjFImyYcLAnLeBGa6sMPgorL2itmO 3Ye7+mToc2q90GRP8Krq1OGSGvX0WfSwyCj/aCfYnG1ZE2c4GkfPiZCQiF++sWTPvREL brWEFJHSLRpzBNeNUSWldnVbCWtH9w+3ckZBU9GwbHLdwpDJVs/N1pKIGgbv/dUQRoUS bbe0JXD6P6zvoUFzkjCOS401IwmkGLcN3uQSi+MZiaXOXFgNCxZMooOeWFTNQY7/Y7Ha FZvWhrF5wOuhbd50xYjwcMH/1O4yYqvjeLClQkZx+DU5SLtWj7gbi4dpjb37CUS9fVcH ywiQ== X-Received: by 10.50.25.100 with SMTP id b4mr17473790igg.17.1416119971422; Sat, 15 Nov 2014 22:39:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.245.163 with HTTP; Sat, 15 Nov 2014 22:38:51 -0800 (PST) From: Bogdan SOLGA Date: Sun, 16 Nov 2014 08:38:51 +0200 Message-ID: Subject: ZFS pool creation from files leads to a crash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 06:39:32 -0000 Hello, everyone! Yesterday I have started to test FreeBSD-10.1-RELEASE, using VirtualBox VMs created from the mfsBSD 10.1 image. I installed the system on a 2 GB zpool, with fletcher4 checksumming and LZJB compression. As I need some other ZFS zpools for testing purposes, I have tried to create them from a few empty files, created as follows: # truncate -s 100M /tmp/file1 # truncate -s 100M /tmp/file2 # zpool create test-pool /tmp/zfile1 /tmp/file2 When the 'zpool create' command is executed, it leads to a crash and the VM is automatically restarted. I have searched the crash dump in the logs, but coulnd't find it. The same operation (creating a ZFS pool from files) works properly on FreeBSD-10-RELEASE. Any help is appreciated :) Thank you! Kind regards, Bogdan From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 07:29:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 707E36F6 for ; Sun, 16 Nov 2014 07:29:27 +0000 (UTC) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B4165FB for ; Sun, 16 Nov 2014 07:29:27 +0000 (UTC) Received: by mail-yk0-f174.google.com with SMTP id 10so377340ykt.5 for ; Sat, 15 Nov 2014 23:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=xNvbATkoTQZey4yJDYzGsLD1+1YROAE98BeLGfstgl4=; b=PwZ3dEc5ImAweRG3XFqcOOJayw0CDTqoVBVEdkojW/tCQmMsCpEDCmEs9r0Sx5UshN pAfgpWsiPb9bzWUeHyCmunZcNoRNt12CUc+DcNCG22izjRNSqEPaLG1QMlOp5GDwguFi DrHA3XpHZYRaNk3CbVXGBGBQV7VQXwT09T6g+yONwAZYacvG77XM2bUGw3RGcKNZPJp/ qaUnm+ymuaYaEDXC/sWEzyAi6i8jHoC0XECMdN+sqtsaypeiJFmjPp3mVNU8Fwd1Y/YN 5+II/kZvz4tJazVPaj2J6uz7DVL3HbMQWirVxcWISJGsjCYuQgJjTfRxi6TaN3Byvv6b tFKg== MIME-Version: 1.0 X-Received: by 10.170.98.84 with SMTP id p81mr851774yka.40.1416122966265; Sat, 15 Nov 2014 23:29:26 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Sat, 15 Nov 2014 23:29:26 -0800 (PST) In-Reply-To: References: Date: Sat, 15 Nov 2014 23:29:26 -0800 X-Google-Sender-Auth: FkUwLtMG54fg-g2QUnpaBE4RH8Q Message-ID: Subject: Re: ZFS pool creation from files leads to a crash From: "K. Macy" To: Bogdan SOLGA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 07:29:27 -0000 I can reproduce this easily on head and have a deoptimized kernel so that gdb gives useful information. It looks like the trim changes might have broken this. It's too late for me in PST to try and track this down tonight. Maybe others who have spent more time in this code can chime in in a timely fashion. Otherwise I'll look at it on Monday or Tuesday. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 3; apic id =3D 04 fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80d8373a stack pointer =3D 0x28:0xfffffe01219f66a0 frame pointer =3D 0x28:0xfffffe01219f66b0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1280 (zpool) Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/sem.ko.symbols...done. Loaded symbols for /boot/kernel/sem.ko.symbols #0 doadump (textdump=3D564092400) at /usr/home/kmacy/devel/freebsd-head/sys/kern/kern_shutdown.c:261 261 dumptid =3D curthread->td_tid; (kgdb) bt #0 doadump (textdump=3D564092400) at /usr/home/kmacy/devel/freebsd-head/sys/kern/kern_shutdown.c:261 #1 0xffffffff80361e48 in db_fncall_generic (addr=3D-2137746016, rv=3D0xfffffe01219f5d80, nargs=3D0, args=3D0xfffffe01219f5d90) at /usr/home/kmacy/devel/freebsd-head/sys/ddb/db_command.c:568 #2 0xffffffff80361b1a in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D-2199= 009086476, dummy4=3D0xfffffe01219f5e70 " ^\237!\001=C3=BE=C3=BF=C3=BF\231\022\215\= 200\001") at /usr/home/kmacy/devel/freebsd-head/sys/ddb/db_command.c:616 #3 0xffffffff80361794 in db_command (last_cmdp=3D0xffffffff812a67d8, cmd_table=3D0x0, dopager=3D1) at /usr/home/kmacy/devel/freebsd-head/sys/ddb/db_command.c:440 #4 0xffffffff803613ad in db_command_loop () at /usr/home/kmacy/devel/freebsd-head/sys/ddb/db_command.c:493 #5 0xffffffff803658f8 in db_trap (type=3D12, code=3D0) at /usr/home/kmacy/devel/freebsd-head/sys/ddb/db_main.c:251 #6 0xffffffff809a310c in kdb_trap (type=3D12, code=3D0, tf=3D0xfffffe01219= f65f0) at /usr/home/kmacy/devel/freebsd-head/sys/kern/subr_kdb.c:654 #7 0xffffffff80d87036 in trap_fatal (frame=3D0xfffffe01219f65f0, eva=3D0) at /usr/home/kmacy/devel/freebsd-head/sys/amd64/amd64/trap.c:861 #8 0xffffffff80d872aa in trap_pfault (frame=3D0xfffffe01219f65f0, usermode= =3D0) at /usr/home/kmacy/devel/freebsd-head/sys/amd64/amd64/trap.c:709 #9 0xffffffff80d86240 in trap (frame=3D0xfffffe01219f65f0) at /usr/home/kmacy/devel/freebsd-head/sys/amd64/amd64/trap.c:426 #10 0xffffffff80d87918 in trap_check (frame=3D0xfffffe01219f65f0) at /usr/home/kmacy/devel/freebsd-head/sys/amd64/amd64 /trap.c:620 #11 0xffffffff80d5b9f2 in calltrap () at /usr/home/kmacy/devel/freebsd-head/sys/amd64/amd64/exception.S:231 #12 0xffffffff80d8373a in bcopy () at /usr/home/kmacy/devel/freebsd-head/sys/amd64/amd64/support.S:119 #13 0xffffffff809c6f97 in uiomove_faultflag (cp=3D0xfffffe0005e0e000, n=3D131072, uio=3D0xfffffe01219f6d78, nofault=3D0) at /usr/home/kmacy/devel/freebsd-head/sys/kern/subr_uio.c:208 #14 0xffffffff809c6cd5 in uiomove (cp=3D0xfffffe0005e0e000, n=3D131072, uio=3D0xfffffe01219f6d78) at /usr/home/kmacy/devel/freebsd-head/sys/kern/subr_uio.c:142 #15 0xffffffff8191810d in zfs_uiomove (cp=3D0xfffffe0005e0e000, n=3D131072, dir=3DUIO_WRITE, uio=3D0xfffffe01219f6d78) at uio.h:81 #16 0xffffffff81914df6 in dmu_write_uio_dnode (dn=3D0xfffff8006e78cb70, uio=3D0xfffffe01219f6d78, size=3D131072, tx=3D0xfffff800098f5600) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/= fs/zfs/dmu.c:1171 #17 0xffffffff81914be3 in dmu_write_uio_dbuf (zdb=3D0xfffff8005d975408, uio=3D0xfffffe01219f6d78, size=3D131072, tx=3D0xfffff800098f5600) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/= fs/zfs/dmu.c:1209 #18 0xffffffff81a4a698 in zfs_write (vp=3D0xfffff8005d94a3b0, uio=3D0xfffffe01219f6d78, ioflag=3D128, cr=3D0xfffff80002cd9000, ct=3D0x0) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/openso= laris/uts/common/fs/zfs/zfs_vnops.c:1051 #19 0xffffffff81a4106e in zfs_freebsd_write (ap=3D0xfffffe01219f6ca8) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zfs_vnops.c:6104 #20 0xffffffff80e9fc50 in VOP_WRITE_APV (vop=3D0xffffffff81ae6600, a=3D0xfffffe01219f6ca8) at vnode_if.c:997 #21 0xffffffff80a7508e in VOP_WRITE (vp=3D0xfffff8005d94a3b0, uio=3D0xfffffe01219f6d78, ioflag=3D128, cred=3D0xfffff80002cd9000) at vnode_if.h:413 #22 0xffffffff80a74932 in vn_rdwr (rw=3DUIO_WRITE, vp=3D0xfffff8005d94a3b0, base=3D0x0, len=3D104857600, offset=3D0, segflg=3DUIO_SYSSPACE, ioflg=3D128, active_cred=3D0xfffff80002cd9000, file_cred=3D0x0, aresid=3D0xfffffe01219f6e50, td=3D0xfffff80009ac14a0) at /usr/home/kmacy/devel/freebsd-head/sys/kern/vfs_vnops.c:559 #23 0xffffffff819b9a2c in zfs_vn_rdwr (rw=3DUIO_WRITE, vp=3D0xfffff8005d94a3b0, base=3D0x0, len=3D104857600, offset=3D0, seg=3DUIO_SYSSPACE, ioflag=3D128, ulimit=3D0, cr=3D0xfffff80002cd9000, residp=3D0xfffffe01219f6f18) at vnode.h:237 #24 0xffffffff819b9706 in vdev_file_io_start (zio=3D0xfffff80009ebb000) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/vdev_file.c:188 #25 0xffffffff819fcea3 in zio_vdev_io_start (zio=3D0xfffff80009ebb000) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zio.c:2709 #26 0xffffffff819f51f1 in zio_execute (zio=3D0xfffff80009ebb000) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zio.c:1409 #27 0xffffffff819f368a in zio_wait (zio=3D0xfffff80009ebb000) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zio.c:1433 #28 0xffffffff819bb51e in vdev_label_init (vd=3D0xfffff80009919800, crtxg=3D4, reason=3DVDEV_LABEL_CREATE) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/vdev_label.c:718 #29 0xffffffff819bb0f9 in vdev_label_init (vd=3D0xfffff8000991a000, crtxg=3D4, reason=3DVDEV_LABEL_CREATE) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/vdev_label.c:642 #30 0xffffffff819b2ab6 in vdev_create (vd=3D0xfffff8000991a000, txg=3D4, isreplacing=3D0) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/vdev.c:1662 #31 0xffffffff8198cd7b in spa_create (pool=3D0xfffffe0005e4e000 "test-pool", nvroot=3D0xfffff80009511d60, props=3D0xfffff8006e277580, zplprops=3D0xfffff800097317e0) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/spa.c:3617 #32 0xffffffff81a218fe in zfs_ioc_pool_create (zc=3D0xfffffe0005e4e000) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zfs_ioctl.c:1542 #33 0xffffffff81a1de0d in zfsdev_ioctl (dev=3D0xfffff80007125c00, zcmd=3D3222821376, arg=3D0xfffffe01219f78a0 "\004", flag=3D3, td=3D0xfffff80009ac14a0) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zfs_ioctl.c:6198 #34 0xffffffff80783c23 in devfs_ioctl_f (fp=3D0xfffff800096b4280, com=3D3222821376, data=3D0xfffffe01219f78a0, cred=3D0xfffff80002cd6600, td=3D0xfffff80009ac14a0) at /usr/home/kmacy#13 0xffffffff809c6f97 in uiomove_faultflag (cp=3D0xfffffe0005e0e000, n=3D131072, uio=3D0xfffffe01219f6d78, nofault=3D0= ) at /usr/home/kmacy/devel/freebsd-head/sys/kern/subr_uio.c:208 208 bcopy(iov->iov_base, cp, cnt); Current language: auto; currently minimal (kgdb) p iov->iov_base $1 =3D (void *) 0x0 (kgdb) p *iov $2 =3D {iov_base =3D 0x0, iov_len =3D 104857600} /devel/freebsd-head/sys/fs/devfs/devfs_vnops.c:775 (kgdb) f 28 #28 0xffffffff819bb51e in vdev_label_init (vd=3D0xfffff80009919800, crtxg=3D4, reason=3DVDEV_LABEL_CREATE) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/vdev_label.c:718 718 zio_wait(zio_trim(NULL, spa, vd, 0, vd->vdev_psize));kgdb) down #27 0xffffffff819f368a in zio_wait (zio=3D0xfffff80009ebb000) at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zio.c:1433 1433 zio_execute(zio); (kgdb) p zio->io_data $2 =3D (void *) 0x0 (kgdb) f 23 #23 0xffffffff819b9a2c in zfs_vn_rdwr (rw=3DUIO_WRITE, vp=3D0xfffff8005d94a3b0, base=3D0x0, len=3D104857600, offset=3D0, seg=3DUIO_SYSSPACE, ioflag=3D128, ulimit=3D0, cr=3D0xfffff80002cd9000, residp=3D0xfffffe01219f6f18) at vnode.h:237 237 error =3D vn_rdwr(rw, vp, base, len, offset, seg, ioflag, cr, NOCRED, (kgdb) p base $3 =3D 0x0 On Sat, Nov 15, 2014 at 10:38 PM, Bogdan SOLGA wro= te: > Hello, everyone! > > Yesterday I have started to test FreeBSD-10.1-RELEASE, using VirtualBox V= Ms > created from the mfsBSD 10.1 image. I installed th= e > system on a 2 GB zpool, with fletcher4 checksumming and LZJB compression. > > As I need some other ZFS zpools for testing purposes, I have tried to > create them from a few empty files, created as follows: > # truncate -s 100M /tmp/file1 > # truncate -s 100M /tmp/file2 > # zpool create test-pool /tmp/zfile1 /tmp/file2 > > When the 'zpool create' command is executed, it leads to a crash and the = VM > is automatically restarted. I have searched the crash dump in the logs, b= ut > coulnd't find it. > > The same operation (creating a ZFS pool from files) works properly on > FreeBSD-10-RELEASE. > > Any help is appreciated :) > > Thank you! > > Kind regards, > Bogdan > _______________________________________________ > 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 Sun Nov 16 08:05:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9C50DE7 for ; Sun, 16 Nov 2014 08:05:54 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE52596E for ; Sun, 16 Nov 2014 08:05:54 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XpuqG-000CMC-0K for freebsd-stable@freebsd.org; Sun, 16 Nov 2014 09:05:52 +0100 Date: Sun, 16 Nov 2014 09:05:51 +0100 From: Kurt Jaeger To: freebsd-stable@freebsd.org Subject: 10.1-RELEASE ISOs missing at some place ? Message-ID: <20141116080551.GA44537@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 08:05:55 -0000 Hi! On https://www.freebsd.org/releases/10.1R/announce.html there is a link to download the ISOs. If I follow those link to: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ there are no ISOs for -RELEASE ? This link works (for amd64): ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/10.1/ -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 08:23:17 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70AC9FFC; Sun, 16 Nov 2014 08:23:17 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 95293AE3; Sun, 16 Nov 2014 08:23:16 +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 KAA14315; Sun, 16 Nov 2014 10:25:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Xpv73-00008C-1i; Sun, 16 Nov 2014 10:23:13 +0200 Message-ID: <54685EB8.9050800@FreeBSD.org> Date: Sun, 16 Nov 2014 10:22:16 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "K. Macy" , Bogdan SOLGA Subject: Re: ZFS pool creation from files leads to a crash References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 08:23:17 -0000 On 16/11/2014 09:29, K. Macy wrote: > #23 0xffffffff819b9a2c in zfs_vn_rdwr (rw=UIO_WRITE, > vp=0xfffff8005d94a3b0, base=0x0, len=104857600, offset=0, > seg=UIO_SYSSPACE, ioflag=128, ulimit=0, cr=0xfffff80002cd9000, > residp=0xfffffe01219f6f18) at vnode.h:237 > #24 0xffffffff819b9706 in vdev_file_io_start (zio=0xfffff80009ebb000) > at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c:188 > #25 0xffffffff819fcea3 in zio_vdev_io_start (zio=0xfffff80009ebb000) > at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2709 > #26 0xffffffff819f51f1 in zio_execute (zio=0xfffff80009ebb000) > at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1409 > #27 0xffffffff819f368a in zio_wait (zio=0xfffff80009ebb000) > at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1433 > #28 0xffffffff819bb51e in vdev_label_init (vd=0xfffff80009919800, > crtxg=4, reason=VDEV_LABEL_CREATE) > at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c:718 Seems like this crash is caused by vdev_file_io_start being blissfully unaware of ZIO_TYPE_FREE. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 08:42:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52CA0342 for ; Sun, 16 Nov 2014 08:42:57 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB635C79 for ; Sun, 16 Nov 2014 08:42:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sAG8ghPI015964; Sun, 16 Nov 2014 19:42:44 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 16 Nov 2014 19:42:43 +1100 (EST) From: Ian Smith To: Kevin Oberman Subject: Re: Upgrade from 10.1-RC3 to 10.1-RELEASE using freebsd-update In-Reply-To: Message-ID: <20141116191816.K31139@sola.nimnet.asn.au> References: <1416065576.26947.YahooMailNeo@web190701.mail.sg3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Masoom Shaikh , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 08:42:57 -0000 On Sat, 15 Nov 2014 11:41:03 -0800, Kevin Oberman wrote: [..] > You're using the wrong command to freebsd-update. > # freebsd-update upgrade -r 10.1-RELEASE > > "fetch" is appropriate to updating for patches to the release you are > currently running. > > Since you installed from a USB distribution, there is no rollback. The > rollback data is created by freebsd-update. > > Also, I suspect you entered the data above from memory as freebsd-upgrade > is not a command in base freebsd. Personally I find usage of the terms 'update' and 'upgrade' bound to lead to problems; they are not far enough from synonymous in common English usage. C.O.D. has it thus: update v.t. Bring up to date. upgrade v.t. Raise in rank etc. freebsd-update(8) is reasonably clear about what upgrade means, but I'm still finding usage of these terms in pkg-update(8) and pkg-upgrade(8) regularly confusing especially as searching either for 'update|upgrade' shows plenty of hits for both. Perhaps less of an issue for non-native English speakers/authors? cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 09:10:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ADDA6D1 for ; Sun, 16 Nov 2014 09:10:23 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5D00E14 for ; Sun, 16 Nov 2014 09:10:22 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id m8so14376470obr.24 for ; Sun, 16 Nov 2014 01:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MjeBn4pwcaBXO4DNdRc1ntH+FGu5nX3CUUQf8XZE3hA=; b=VMg/yHwospm9dmMnJQ87PQFmxmIU83nH9d8r+2LYkM1GI7CYCwmda/Dp7M6EIIBi9m b8SxS4vna59/KU12olnIuc6O1mqghDePmm9ZaBSTBhUuMmTQzYKV8VT4UMmegvl9pD7V mV+dTR+SXr3pVo53iYjEuzNPLOgHD+np4HUtaN779zBO4hYg4whtIdFC+PXiTFqPsUok IyA/zZxBlXyy4vkvM0LAatmTFLK2+0VU4OwrqjdVS+yuYYixRw8YR6Dnox2RdceUlq4y wq9P22umYd3YXc0/Q3jJ/4GrVXY6XhSmUveB1BePZLxOh7yGaORnVuAm0An/K1IcOBTs 4V0w== MIME-Version: 1.0 X-Received: by 10.60.155.34 with SMTP id vt2mr17820227oeb.34.1416129022063; Sun, 16 Nov 2014 01:10:22 -0800 (PST) Received: by 10.182.171.73 with HTTP; Sun, 16 Nov 2014 01:10:22 -0800 (PST) Date: Sun, 16 Nov 2014 01:10:22 -0800 Message-ID: Subject: cvmx-srio.c From: jungle Boogie To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 09:10:23 -0000 Hello All, You may be aware of the Edge Router Lite[0] (ERL) and that it can run FreeBSD in place of the GNU/Linux/Debian kernel, OS, etc that it comes standard with. Well a cool FreeBSD guy, Nathan Dorfman, created a script that allows you to build a freeBSD image that you can run on your ERL. The only caveat is that you need to be running a freeBSD that you want to also run on the ERL. The other day I had my 10-stable machine spend about two days making the image with Nathan's script[1]. # uname -a FreeBSD pulse 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r274439: Wed Nov 12 15:07:52 PST 2014 root@pulse:/usr/obj/usr/src/ sys/GENERIC i386 New VM: # uname -a FreeBSD build 10.1-STABLE FreeBSD 10.1-STABLE #0 r274578: Sat Nov 15 23:55:08 PST 2014 root@build:/usr/obj/usr/src/sys/GENERIC amd64 That image was made fine and its running on the ERL. Now I want to update to post 10.1-RELEASE on a VM but it fails: Full file here: http://108.61.218.154/erl.txt /usr/src/sys/contrib/octeon-sdk/cvmx-srio.c --- cvmx-helper-sgmii.o --- cc: Internal error: Killed (program cc1) Please submit a full bug report. See for instructions. --- cvmx-helper-srio.o --- cc: Internal error: Killed (program cc1) Please submit a full bug report. See for instructions. --- cvmx-helper-sgmii.o --- *** [cvmx-helper-sgmii.o] Error code 1 make[2]: stopped in /usr/obj/mips.mips64/usr/src/sys/ERL --- cvmx-helper-srio.o --- *** [cvmx-helper-srio.o] Error code 1 make[2]: stopped in /usr/obj/mips.mips64/usr/src/sys/ERL --- cvmx-pko.o --- cc: Internal error: Killed (program cc1) Please submit a full bug report. See for instructions. *** [cvmx-pko.o] Error code 1 make[2]: stopped in /usr/obj/mips.mips64/usr/src/sys/ERL --- cvmx-spi.o --- cc: Internal error: Killed (program cc1) Please submit a full bug report. See for instructions. *** [cvmx-spi.o] Error code 1 make[2]: stopped in /usr/obj/mips.mips64/usr/src/sys/ERL 4 errors make[2]: stopped in /usr/obj/mips.mips64/usr/src/sys/ERL *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Does the script need to be updated? Am I using the wrong arch? Is something in 10-stable broken? I'm also updating the machine I originally tried this on as well as I setup a new VM and I'm converting it to 11-current and I'll try the same script on it as well. Thanks, jb [0] http://www.ubnt.com/edgemax/edgerouter-lite/ [1] http://rtfm.net/FreeBSD/ERL/mkerlimage -- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 09:14:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F15D800 for ; Sun, 16 Nov 2014 09:14:58 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FEE8ECD for ; Sun, 16 Nov 2014 09:14:58 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hi2so1486737wib.5 for ; Sun, 16 Nov 2014 01:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L9QfM5etMG2NuuYfrTBdZProNzOnMmEs1YKIJ+8ZhnI=; b=N7ZcwY7oronRag4WvV44wFaZnT95smbogqhD5k/895kRbZOtbkZoPw3UrAF8Z59lfK YnM/tofpB/xb8eRR6etI0cnY5bY6IwXrJZJGwK4G0oYVZ4InoeRkodffU+e08N1Z8wYq P/7OUWTg4C2GcTu7g1z3foKsK/6Z0ZS5maTXoTYG4+DhSmGYPqv1WAx94VLD21dCIxSd tTVd8Mc5qZi4UUdPLvUNUSoI34diJmqYb0QLE/MHNaCnPP3USB27/WPwOym2yzcnI8Rg m88bqCoYjtDPMMZq9rKY6YjsViJEG98nnOrj2P5olslssSOTlGPgV42VhEmaBsg8Zk+I zPdA== MIME-Version: 1.0 X-Received: by 10.194.193.2 with SMTP id hk2mr15547716wjc.40.1416129296411; Sun, 16 Nov 2014 01:14:56 -0800 (PST) Received: by 10.216.118.72 with HTTP; Sun, 16 Nov 2014 01:14:56 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Nov 2014 04:14:56 -0500 Message-ID: Subject: Re: cvmx-srio.c From: Brandon Allbery To: jungle Boogie Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 09:14:58 -0000 On Sun, Nov 16, 2014 at 4:10 AM, jungle Boogie wrote: > cc: Internal error: Killed (program cc1) > Reasons to get that: - missing or invalid shared object (normally you'd see a diagnostic before the SIGKILL) - "hard" out of virtual memory (most probable) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 10:32:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 786AC78F for ; Sun, 16 Nov 2014 10:32:43 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BC197DB for ; Sun, 16 Nov 2014 10:32:43 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id nt9so15720184obb.41 for ; Sun, 16 Nov 2014 02:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y+QmndvhKAlPhzjHfFlOeKa+ooVY95iiIo0EdiSJrNE=; b=q1bGXplyTSjp5FnKXevt8SsukvNmYtVZXIb9iYA9j2VDiymMYj/+yTJPwWJtjOvtiV RoRLoeeqZvUK0x2mqvFhdMvdqmHzZ6TBYYMOfe/5YRCZC4221/n/Q0Y4die+XimcBxQB wTRoJywigwx1K/Snvqftn5OwGbn5d87Q8LoJrlDI0vIOIeFMKXhevf8TtgP+HXWBIgD+ gxjHq22Ebp6lAmf6qKLm1t1ZYiySr1zvWfXY3UYeu9Furn+tfqFGUJGREZTnLvUCzmyL nKkcbrDVY/5GHa8XEmeuC2zg5zmIxTgPJVCSURc8TIVtzi08rbM/vmb9/7EzLue7DgnO 7LLA== MIME-Version: 1.0 X-Received: by 10.60.55.200 with SMTP id u8mr1212912oep.43.1416133962359; Sun, 16 Nov 2014 02:32:42 -0800 (PST) Received: by 10.182.171.73 with HTTP; Sun, 16 Nov 2014 02:32:42 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Nov 2014 02:32:42 -0800 Message-ID: Subject: Re: cvmx-srio.c From: jungle Boogie To: Brandon Allbery Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 10:32:43 -0000 Hi Brandon, On 16 November 2014 01:14, Brandon Allbery wrote: > On Sun, Nov 16, 2014 at 4:10 AM, jungle Boogie > wrote: >> >> cc: Internal error: Killed (program cc1) > > > Reasons to get that: > - missing or invalid shared object (normally you'd see a diagnostic before > the SIGKILL) > - "hard" out of virtual memory (most probable) > Well interestingly the VM I used had more resources than the bare metal that took 1-2 days to complete. I'll see about trying a higher memory usage VM to see if it fails. I'm making the VMs here: https://www.vultr.com/pricing/ By the way, the 11-current failed with same message. :( > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 13:13:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDC351F7 for ; Sun, 16 Nov 2014 13:13:10 +0000 (UTC) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A468783 for ; Sun, 16 Nov 2014 13:13:10 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id sAGDCl6j005988 for ; Sun, 16 Nov 2014 08:13:07 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <5468A2CF.7030303@m5p.com> Date: Sun, 16 Nov 2014 08:12:47 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Upgrade from 10.1-RC3 to 10.1-RELEASE using freebsd-update References: <1416065576.26947.YahooMailNeo@web190701.mail.sg3.yahoo.com> <20141116191816.K31139@sola.nimnet.asn.au> In-Reply-To: <20141116191816.K31139@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 16 Nov 2014 08:13:07 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 13:13:10 -0000 On 11/16/14 03:42, Ian Smith wrote: > On Sat, 15 Nov 2014 11:41:03 -0800, Kevin Oberman wrote: > [..] > > You're using the wrong command to freebsd-update. > > # freebsd-update upgrade -r 10.1-RELEASE > > > > "fetch" is appropriate to updating for patches to the release you are > > currently running. > > > > Since you installed from a USB distribution, there is no rollback. The > > rollback data is created by freebsd-update. > > > > Also, I suspect you entered the data above from memory as freebsd-upgrade > > is not a command in base freebsd. > > Personally I find usage of the terms 'update' and 'upgrade' bound to > lead to problems; they are not far enough from synonymous in common > English usage. C.O.D. has it thus: update v.t. Bring up to date. > upgrade v.t. Raise in rank etc. > [...] I'll see your confusion and raise you a question about why "pkg update" is even a separate option, since "pkg upgrade" will do it for you by default. Personally I have trained myself that "pkg update" isn't what I want and that I should always type "pkg upgrade". -- George From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 16:15:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EFFBE92 for ; Sun, 16 Nov 2014 16:15:15 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 145279E3 for ; Sun, 16 Nov 2014 16:15:14 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so22777060wgh.11 for ; Sun, 16 Nov 2014 08:15:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KeAzv8rTEfMxOyB5yzCdRbkBh7GCsyis/k72W/bM2KA=; b=Jk9szBULRDcMHsh1DQ87Bc5Wf4T79X5DOR5f6Y1DFQg5jLOK5IovFboX7n4t/dHG84 jdoxa5gnQSzSeUjkcwfE6I1LiBONCaY/8sH9K2m3eXDrrcHdIN8YGRPBwqS5GJZ/zn/k tCxGWhEZyNJz7ML/XWMvto30JoWiOPoAQnRVAdXS8mN6gCQ34Atp6ShJLJCisS9istgz HNu/cUQ4GRbSwyn3IcwlkgIBqwPtvd60Z/dy6ZQwhNavZ3EAjffPmDBrJJU+AIHxBhBg tz7ek5DY0I9eXCKxpXbzKLq6mke2MGuF6hGRkdcbT/ucFlZ9wh62fxFU2WUravbaNtZ1 SCmQ== X-Gm-Message-State: ALoCoQlNeNt/Gkj5ROftiCaHyn6BgkdhQ3nIQxIyFVCnkmft7ZZntA4sXzAQp1SIV3IHBF31kpxC X-Received: by 10.194.250.68 with SMTP id za4mr31935559wjc.92.1416154507154; Sun, 16 Nov 2014 08:15:07 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id lp14sm11596785wic.20.2014.11.16.08.15.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Nov 2014 08:15:05 -0800 (PST) Message-ID: <5468CD8C.7070500@multiplay.co.uk> Date: Sun, 16 Nov 2014 16:15:08 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ZFS pool creation from files leads to a crash References: <54685EB8.9050800@FreeBSD.org> In-Reply-To: <54685EB8.9050800@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 16:15:15 -0000 On 16/11/2014 08:22, Andriy Gapon wrote: > On 16/11/2014 09:29, K. Macy wrote: >> #23 0xffffffff819b9a2c in zfs_vn_rdwr (rw=UIO_WRITE, >> vp=0xfffff8005d94a3b0, base=0x0, len=104857600, offset=0, >> seg=UIO_SYSSPACE, ioflag=128, ulimit=0, cr=0xfffff80002cd9000, >> residp=0xfffffe01219f6f18) at vnode.h:237 >> #24 0xffffffff819b9706 in vdev_file_io_start (zio=0xfffff80009ebb000) >> at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c:188 >> #25 0xffffffff819fcea3 in zio_vdev_io_start (zio=0xfffff80009ebb000) >> at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2709 >> #26 0xffffffff819f51f1 in zio_execute (zio=0xfffff80009ebb000) >> at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1409 >> #27 0xffffffff819f368a in zio_wait (zio=0xfffff80009ebb000) >> at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1433 >> #28 0xffffffff819bb51e in vdev_label_init (vd=0xfffff80009919800, >> crtxg=4, reason=VDEV_LABEL_CREATE) >> at /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c:718 > Seems like this crash is caused by vdev_file_io_start being blissfully unaware > of ZIO_TYPE_FREE. > It is indeed see the following bug for breakdown and patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 I'd love to know why I can run this many times over here and not a single sign of a panic :( Regards Steve From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 21:08:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BC7443D for ; Sun, 16 Nov 2014 21:08:28 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 065AE9F7 for ; Sun, 16 Nov 2014 21:08:28 +0000 (UTC) Received: by mail-yk0-f181.google.com with SMTP id 142so4487370ykq.40 for ; Sun, 16 Nov 2014 13:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oght6qLas36MpAlFTaCEDYlzvQ7B2oMVnNTi43sKcVI=; b=mG6LlZJPSU/AUcKenjiBBZ1pMXB81eha7TLVIVbxhi/LkkbncSxsfgZCwHhsl+tbus mDp/E2xwQ8m2kN26yMjf0JdlAC4Qcm+oqicrJ1OK5iJbbZcfMCvnckSUtL7IFU6G/wsd 1/pDiHCX7VYNtcSnl0jCjKVQD+t4EQczq4E8fL2s9nKDtanK261/wDBC+r2xME1uaSD6 nNBEJmKFA5OHbbiDD2PNDAmsgq2jPkzx1c9o2HGQraDQ9UA+HmsOFKGJBlmSPAWL35ot xhy6YxwuETjTTR6Aj3jnLkNpQi/k6A8007wSKUtYWH5tugXh7ffxNxDaR4BLdbF1hz3S fSfA== MIME-Version: 1.0 X-Received: by 10.236.66.40 with SMTP id g28mr21202157yhd.6.1416172107118; Sun, 16 Nov 2014 13:08:27 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Sun, 16 Nov 2014 13:08:27 -0800 (PST) In-Reply-To: <5468CD8C.7070500@multiplay.co.uk> References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> Date: Sun, 16 Nov 2014 13:08:27 -0800 X-Google-Sender-Auth: PUERHa6A0Tf71OsoeOIXrpz9HFk Message-ID: Subject: Re: ZFS pool creation from files leads to a crash From: "K. Macy" To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 21:08:28 -0000 On Sun, Nov 16, 2014 at 8:15 AM, Steven Hartland wrote: > > On 16/11/2014 08:22, Andriy Gapon wrote: >> >> On 16/11/2014 09:29, K. Macy wrote: >>> >>> #23 0xffffffff819b9a2c in zfs_vn_rdwr (rw=UIO_WRITE, >>> vp=0xfffff8005d94a3b0, base=0x0, len=104857600, offset=0, >>> seg=UIO_SYSSPACE, ioflag=128, ulimit=0, cr=0xfffff80002cd9000, >>> residp=0xfffffe01219f6f18) at vnode.h:237 >>> #24 0xffffffff819b9706 in vdev_file_io_start (zio=0xfffff80009ebb000) >>> at >>> /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c:188 >>> #25 0xffffffff819fcea3 in zio_vdev_io_start (zio=0xfffff80009ebb000) >>> at >>> /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2709 >>> #26 0xffffffff819f51f1 in zio_execute (zio=0xfffff80009ebb000) >>> at >>> /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1409 >>> #27 0xffffffff819f368a in zio_wait (zio=0xfffff80009ebb000) >>> at >>> /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1433 >>> #28 0xffffffff819bb51e in vdev_label_init (vd=0xfffff80009919800, >>> crtxg=4, reason=VDEV_LABEL_CREATE) >>> at >>> /usr/home/kmacy/devel/freebsd-head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c:718 >> >> Seems like this crash is caused by vdev_file_io_start being blissfully >> unaware >> of ZIO_TYPE_FREE. >> > It is indeed see the following bug for breakdown and patch: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 > > I'd love to know why I can run this many times over here and not a single > sign of a panic :( Do you somehow have TRIM disabled? -K From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 21:13:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 631CB73C for ; Sun, 16 Nov 2014 21:13:18 +0000 (UTC) Received: from nagini.codelibre.net (nagini.codelibre.net [IPv6:2001:41c8:1:5750::2]) by mx1.freebsd.org (Postfix) with ESMTP id BE2F2AAD for ; Sun, 16 Nov 2014 21:13:17 +0000 (UTC) Received: by nagini.codelibre.net (Postfix, from userid 1000) id 6AF36182E1; Sun, 16 Nov 2014 21:13:16 +0000 (GMT) Date: Sun, 16 Nov 2014 21:13:16 +0000 From: Roger Leigh To: freebsd-stable@freebsd.org Subject: Re: PCI-E SATA-III HBA for FreeBSD 10 Message-ID: <20141116211316.GM1657@codelibre.net> References: <20140817171554.GB7997@codelibre.net> <20140822101014.GE7997@codelibre.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140822101014.GE7997@codelibre.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 21:13:18 -0000 On Fri, Aug 22, 2014 at 11:10:14AM +0100, Roger Leigh wrote: > On Mon, Aug 18, 2014 at 12:35:35PM +0000, Tom Evans wrote: > > Cards supported by mps(4), eg LSI SAS2008 based cards, are very well > > supported and very fast. Flash to "IT mode" for use with ZFS. > > Many thanks for the suggestion, I'll look into one of these. I have followed this suggestion and bought an LSI SAS 9211-4i (SAS2004) board and flashed it with the "IT" firmware after installation into my HP N40L microserver. It's being detected at boot and also finding the attached SSDs, but I'm getting a lot of strange errors. Could anyone suggest what might be at fault here? The board has an SFF-8087 breakout cable attached which has 4 SATA connectors which are plugged into a SATA backplane. This has 3 SATA-III SSDs installed into it: - a Crucial M550 256GB SATA-III drive - 2x Trancend SSD370 64GB SATA-III drives The server is now running 10.1-RELEASE. At boot I get some SATA errors, and when running "diskutil -t" or "dd" I get screeds of errors in the kernel logs, and the "dd" I/O throughput is in the low 10s of Mb/s rather than ~400+ as expected. Booting with an Ubuntu 10.10 live USB drive gives the expected throughput for the Transcend drives with zero errors, while I still get some errors for the Crucial SSD. Google suggests that this might be due to using SATA drives rather than SAS which don't do tagged command queuing, but not sure if this applies here. Are there any mpt/da or other settings which need tweaking to work with SATA-III drives? Not sure if this is a hardware/cable/drive/kernel driver fault, but I've tested the SSDs in a different system where they work perfectly (they are brand new). Given the difference in behaviour with Ubuntu it looks like it might be the mps/da drivers, but not entirely sure. Thanks, Roger # dmesg FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD Turion(tm) II Neo N54L Dual-Core Processor (2196.47-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f63 Family = 0x10 Model = 0x6 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x837ff TSC: P-state invariant [...] mps0: port 0xe000-0xe0ff mem 0xfe8fc000-0xfe8fffff,0xfe880000-0xfe8bffff irq 18 at device 0.0 on pci2 mps0: Firmware: 20.00.00.00, Driver: 19.00.00.00-fbsd mps0: IOCCapabilities: 1285c [...] da1 at mps0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-6 device da1: Serial Number B492480406 da1: 600.000MB/s transfers da1: Command Queueing enabled da1: 61057MB (125045424 512 byte sectors: 255H 63S/T 7783C) da0 at mps0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number 14200C21AE4B da0: 600.000MB/s transfers da0: Command Queueing enabled da0: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) da2 at mps0 bus 0 scbus0 target 2 lun 0 da2: Fixed Direct Access SCSI-6 device da2: Serial Number B492480446 da2: 600.000MB/s transfers da2: Command Queueing enabled da2: 61057MB (125045424 512 byte sectors: 255H 63S/T 7783C) (da1:mps0:0:1:0): READ(6). CDB: 08 00 00 02 20 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(10). CDB: 28 00 00 00 01 28 00 01 00 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) # diskinfo -t /dev/da0 /dev/da0 512 # sectorsize 256060514304 # mediasize in bytes (238G) 500118192 # mediasize in sectors 4096 # stripesize 0 # stripeoffset 31130 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 14200C21AE4B # Disk ident. Seek times: Full stroke: 250 iter in 0.091963 sec = 0.368 msec Half stroke: 250 iter in 0.084927 sec = 0.340 msec Quarter stroke: 500 iter in 0.133857 sec = 0.268 msec Short forward: 400 iter in 0.078823 sec = 0.197 msec Short backward: 400 iter in 0.081324 sec = 0.203 msec Seq outer: 2048 iter in 0.379553 sec = 0.185 msec Seq inner: 2048 iter in 0.115075 sec = 0.056 msec Transfer rates: outside: 102400 kbytes in 0.491958 sec = 208148 kbytes/sec middle: 102400 kbytes in 0.583785 sec = 175407 kbytes/sec inside: 102400 kbytes in 1.294205 sec = 79122 kbytes/sec # dmesg (da0:mps0:0:0:0): READ(6). CDB: 08 00 07 c1 40 00 length 32768 SMID 680 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 0c d9 f8 00 length 126976 SMID 687 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 1d d1 f8 00 length 126976 SMID 707 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 1e c9 f8 00 length 126976 SMID 709 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 2c d9 f8 00 length 126976 SMID 726 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 2c d9 f8 00 length 126976 SMID 727 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 8c d9 f8 00 length 126976 SMID 836 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 a8 f9 f8 00 length 126976 SMID 869 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 d4 d9 f8 00 length 126976 SMID 919 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 e9 f1 f8 00 length 126976 SMID 944 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 eb e1 f8 00 length 126976 SMID 947 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 eb e1 f8 00 length 126976 SMID 948 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 00 01 f8 00 length 126976 SMID 972 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 31 f1 f8 00 length 126976 SMID 66 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 45 d1 f8 00 length 126976 SMID 89 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 96 c9 f8 00 length 126976 SMID 181 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 a5 d1 f8 00 length 126976 SMID 199 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 f1 f1 f8 00 length 126976 SMID 286 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 70 f9 f8 00 length 126976 SMID 430 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 8a e9 f8 00 length 126976 SMID 460 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 b0 f9 f8 00 length 126976 SMID 504 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 eb e1 f8 00 length 126976 SMID 571 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 28 20 00 00 f8 00 length 126976 SMID 666 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 2b 48 00 00 f8 00 length 126976 SMID 671 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 53 48 00 00 f8 00 length 126976 SMID 717 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 71 18 00 00 40 00 length 32768 SMID 751 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 79 18 00 00 40 00 length 32768 SMID 761 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 50 20 00 00 f8 00 length 126976 SMID 1004 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 5a 50 00 00 f8 00 length 126976 SMID 1017 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 5d 38 00 00 f8 00 length 126976 SMID 1021 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 64 40 00 00 f8 00 length 126976 SMID 67 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 66 30 00 00 f8 00 length 126976 SMID 70 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 6b 48 00 00 f8 00 length 126976 SMID 77 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 89 58 00 00 f8 00 length 126976 SMID 112 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 a0 20 00 00 f8 00 length 126976 SMID 138 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 a2 50 00 00 f8 00 length 126976 SMID 142 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 a2 50 00 00 f8 00 length 126976 SMID 143 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 af 28 00 00 f8 00 length 126976 SMID 158 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 c8 20 00 00 f8 00 length 126976 SMID 187 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 10 20 00 00 f8 00 length 126976 SMID 269 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 2d 38 00 00 f8 00 length 126976 SMID 303 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 31 18 00 00 40 00 length 32768 SMID 308 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 3e 30 00 00 f8 00 length 126976 SMID 324 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 83 48 00 00 f8 00 length 126976 SMID 403 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 95 38 00 00 f8 00 length 126976 SMID 424 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 ad 38 00 00 f8 00 length 126976 SMID 452 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 ae 30 00 00 f8 00 length 126976 SMID 454 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 dd 38 00 00 f8 00 length 126976 SMID 508 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e9 05 38 00 00 f8 00 length 126976 SMID 554 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e9 09 18 00 00 40 00 length 32768 SMID 559 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e9 09 18 00 00 40 00 length 32768 SMID 560 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 29 78 00 00 f8 00 length 126976 SMID 624 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 31 78 00 00 f8 00 length 126976 SMID 634 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 4a b0 00 00 f8 00 length 126976 SMID 664 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 85 98 00 00 f8 00 length 126976 SMID 731 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc b3 a8 00 00 f8 00 length 126976 SMID 784 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc be 90 00 00 f8 00 length 126976 SMID 797 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 22 70 00 00 40 00 length 32768 SMID 910 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 47 88 00 00 f8 00 length 126976 SMID 953 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 53 a8 00 00 f8 00 length 126976 SMID 968 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 65 98 00 00 f8 00 length 126976 SMID 989 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 7a b0 00 00 f8 00 length 126976 SMID 1014 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 8a 70 00 00 40 00 length 32768 SMID 69 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd a3 a8 00 00 f8 00 length 126976 SMID 98 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd ab a8 00 00 f8 00 length 126976 SMID 109 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd b7 88 00 00 f8 00 length 126976 SMID 123 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd d2 70 00 00 40 00 length 32768 SMID 154 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 01 78 00 00 f8 00 length 126976 SMID 208 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 16 90 00 00 f8 00 length 126976 SMID 233 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 49 78 00 00 f8 00 length 126976 SMID 291 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 96 90 00 00 f8 00 length 126976 SMID 379 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 99 78 00 00 f8 00 length 126976 SMID 383 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce a0 80 00 00 f8 00 length 126976 SMID 392 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce af 88 00 00 f8 00 length 126976 SMID 410 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce af 88 00 00 f8 00 length 126976 SMID 411 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce e7 88 00 00 f8 00 length 126976 SMID 475 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce ec a0 00 00 f8 00 length 126976 SMID 482 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce ed 98 00 00 f8 00 length 126976 SMID 484 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce f3 a8 00 00 f8 00 length 126976 SMID 492 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cf 12 70 00 00 40 00 length 32768 SMID 527 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cf 1d 98 00 00 f8 00 length 126976 SMID 541 terminated ioc 804b scsi 0 state 0 xfer 0 # diskinfo -t /dev/da1 /dev/da1 512 # sectorsize 64023257088 # mediasize in bytes (60G) 125045424 # mediasize in sectors 0 # stripesize 0 # stripeoffset 7783 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. B492480406 # Disk ident. Seek times: Full stroke: 250 iter in 0.041779 sec = 0.167 msec Half stroke: 250 iter in 0.034729 sec = 0.139 msec Quarter stroke: 500 iter in 0.083738 sec = 0.167 msec Short forward: 400 iter in 0.066829 sec = 0.167 msec Short backward: 400 iter in 0.091763 sec = 0.229 msec Seq outer: 2048 iter in 0.346279 sec = 0.169 msec Seq inner: 2048 iter in 0.137749 sec = 0.067 msec Transfer rates: outside: 102400 kbytes in 0.318925 sec = 321079 kbytes/sec middle: 102400 kbytes in 0.255251 sec = 401174 kbytes/sec inside: 102400 kbytes in 0.259874 sec = 394037 kbytes/sec # dmesg (da1:mps0:0:1:0): READ(6). CDB: 08 00 95 d1 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 00 bd d1 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 00 dc d9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 01 2c d9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 01 49 f1 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 67 c1 40 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 97 c1 40 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 a4 d9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 d6 c9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 03 02 e9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) diskinfo -t /dev/da2 /dev/da2 512 # sectorsize 64023257088 # mediasize in bytes (60G) 125045424 # mediasize in sectors 0 # stripesize 0 # stripeoffset 7783 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. B492480446 # Disk ident. Seek times: Full stroke: 250 iter in 0.102417 sec = 0.410 msec Half stroke: 250 iter in 0.126357 sec = 0.505 msec Quarter stroke: 500 iter in 0.243542 sec = 0.487 msec Short forward: 400 iter in 0.046180 sec = 0.115 msec Short backward: 400 iter in 0.052594 sec = 0.131 msec Seq outer: 2048 iter in 0.262600 sec = 0.128 msec Seq inner: 2048 iter in 0.228124 sec = 0.111 msec Transfer rates: outside: 102400 kbytes in 0.378072 sec = 270848 kbytes/sec middle: 102400 kbytes in 0.314390 sec = 325710 kbytes/sec inside: 102400 kbytes in 0.348791 sec = 293586 kbytes/sec # dmesg (da2:mps0:0:2:0): READ(6). CDB: 08 00 98 f9 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 00 bd d1 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 01 3f c1 40 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 01 a5 d1 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 03 05 d1 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 21:34:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3AD0E3F for ; Sun, 16 Nov 2014 21:34:22 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B6FFC85 for ; Sun, 16 Nov 2014 21:34:22 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xq7SX-0005h2-Cb for freebsd-stable@freebsd.org; Sun, 16 Nov 2014 22:34:13 +0100 Received: from 117.85-200-5.bkkb.no ([85.200.5.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2014 22:34:13 +0100 Received: from christer.solskogen by 117.85-200-5.bkkb.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2014 22:34:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Christer Solskogen Subject: Re: ZFS pool creation from files leads to a crash Date: Sun, 16 Nov 2014 22:34:01 +0100 Lines: 12 Message-ID: References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 117.85-200-5.bkkb.no User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 21:34:22 -0000 On 16.11.2014 22:08, K. Macy wrote: > Do you somehow have TRIM disabled? > Confirmed on real hw (that don't have any SSD's). With vfs.zfs.trim.enabled=0 there is no kernel panic. vfs.zfs.trim.enabled=1 will make it panic. -- chs From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 21:39:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5792E1A9 for ; Sun, 16 Nov 2014 21:39:11 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 129A4CB6 for ; Sun, 16 Nov 2014 21:39:11 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xq7XK-000Dhc-Qp for freebsd-stable@freebsd.org; Sun, 16 Nov 2014 22:39:10 +0100 Date: Sun, 16 Nov 2014 22:39:10 +0100 From: Kurt Jaeger To: freebsd-stable@freebsd.org Subject: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <20141116213910.GF44537@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 21:39:11 -0000 Hi! Under 10.0, we had: da0 at aacraidp1 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device (offline) da0: Serial Number PK1B31P8H5DD2V da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da1 at aacraidp1 bus 0 scbus1 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device (offline) da1: Serial Number PK1B31P8H5L97P da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) Under 10.1, we have: pass0 at aacraidp1 bus 0 scbus1 target 0 lun 0 pass0: Fixed unknown SCSI-5 device (offline) pass0: Serial Number PK1B31P8H5DD2V pass0: 300.000MB/s transfers pass0: Command Queueing enabled pass1 at aacraidp1 bus 0 scbus1 target 1 lun 0 pass1: Fixed unknown SCSI-5 device (offline) pass1: Serial Number PK1B31P8H5L97P pass1: 300.000MB/s transfers pass1: Command Queueing enabled The raid controller: Adaptec 6405E aacraid0: mem 0xf7400000-0xf77fffff,0xf7841000-0xf78417ff,0xf7840000-0xf78400ff irq 17 at device 0.0 on pci2 aacraid0: Enable Raw I/O aacraid0: Enable 64-bit array aacraid0: New comm. interface type1 enabled aacraid0: Adaptec 6405E, aacraid driver 3.2.5-1 aacraidp0 on aacraid0 aacraidp1 on aacraid0 aacraidp2 on aacraid0 aacraidp3 on aacraid0 How do I tell the controller to start those drives and make them visible again ? -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 21:47:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E40F7AE for ; Sun, 16 Nov 2014 21:47:23 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C3C0DB3 for ; Sun, 16 Nov 2014 21:47:23 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id sAGLeaxw011548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Nov 2014 16:40:36 -0500 (EST) (envelope-from mikej@paymentallianceintl.com) Received: from PAIMAIL.pai.local ([::1]) by PAIMAIL.pai.local ([::1]) with mapi; Sun, 16 Nov 2014 16:40:36 -0500 From: Michael Jung To: Roger Leigh , "freebsd-stable@freebsd.org" Date: Sun, 16 Nov 2014 16:36:08 -0500 Subject: RE: PCI-E SATA-III HBA for FreeBSD 10 Thread-Topic: PCI-E SATA-III HBA for FreeBSD 10 Thread-Index: AdAB4itYS1EBu/HURCur1TZ60Tf6WAAAyoEt Message-ID: <9C91F97841BC4347910F206618BAA3BBA3692AB8@PAIMAIL.pai.local> References: <20140817171554.GB7997@codelibre.net> <20140822101014.GE7997@codelibre.net>,<20141116211316.GM1657@codelibre.net> In-Reply-To: <20141116211316.GM1657@codelibre.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 21:47:23 -0000 Roger, Try P19 firmware in IT mode. I just moved a bunch of drives to 9211-8i's a= nd had similar problems with P20 firmware. Downgrading to P19 resolved the issue for me. I would have posted to the list like you but the server changes were in the= middle of the night and I needed a quick resolution. Report back! --mikej ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] O= n Behalf Of Roger Leigh [rleigh@codelibre.net] Sent: Sunday, November 16, 2014 4:13 PM To: freebsd-stable@freebsd.org Subject: Re: PCI-E SATA-III HBA for FreeBSD 10 On Fri, Aug 22, 2014 at 11:10:14AM +0100, Roger Leigh wrote: > On Mon, Aug 18, 2014 at 12:35:35PM +0000, Tom Evans wrote: > > Cards supported by mps(4), eg LSI SAS2008 based cards, are very well > > supported and very fast. Flash to "IT mode" for use with ZFS. > > Many thanks for the suggestion, I'll look into one of these. I have followed this suggestion and bought an LSI SAS 9211-4i (SAS2004) board and flashed it with the "IT" firmware after installation into my HP N40L microserver. It's being detected at boot and also finding the attached SSDs, but I'm getting a lot of strange errors. Could anyone suggest what might be at fault here? The board has an SFF-8087 breakout cable attached which has 4 SATA connectors which are plugged into a SATA backplane. This has 3 SATA-III SSDs installed into it: - a Crucial M550 256GB SATA-III drive - 2x Trancend SSD370 64GB SATA-III drives The server is now running 10.1-RELEASE. At boot I get some SATA errors, and when running "diskutil -t" or "dd" I get screeds of errors in the kernel logs, and the "dd" I/O throughput is in the low 10s of Mb/s rather than ~400+ as expected. Booting with an Ubuntu 10.10 live USB drive gives the expected throughput for the Transcend drives with zero errors, while I still get some errors for the Crucial SSD. Google suggests that this might be due to using SATA drives rather than SAS which don't do tagged command queuing, but not sure if this applies here. Are there any mpt/da or other settings which need tweaking to work with SATA-III drives? Not sure if this is a hardware/cable/drive/kernel driver fault, but I've tested the SSDs in a different system where they work perfectly (they are brand new). Given the difference in behaviour with Ubuntu it looks like it might be the mps/da drivers, but not entirely sure. Thanks, Roger # dmesg FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD Turion(tm) II Neo N54L Dual-Core Processor (2196.47-MHz K8-class C= PU) Origin =3D "AuthenticAMD" Id =3D 0x100f63 Family =3D 0x10 Model =3D 0x= 6 Stepping =3D 3 Features=3D0x178bfbff Features2=3D0x802009 AMD Features=3D0xee500800 AMD Features2=3D0x837ff TSC: P-state invariant [...] mps0: port 0xe000-0xe0ff mem 0xfe8fc000-0xfe8fffff,0xfe880000= -0xfe8bffff irq 18 at device 0.0 on pci2 mps0: Firmware: 20.00.00.00, Driver: 19.00.00.00-fbsd mps0: IOCCapabilities: 1285c [...] da1 at mps0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-6 device da1: Serial Number B492480406 da1: 600.000MB/s transfers da1: Command Queueing enabled da1: 61057MB (125045424 512 byte sectors: 255H 63S/T 7783C) da0 at mps0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number 14200C21AE4B da0: 600.000MB/s transfers da0: Command Queueing enabled da0: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) da2 at mps0 bus 0 scbus0 target 2 lun 0 da2: Fixed Direct Access SCSI-6 device da2: Serial Number B492480446 da2: 600.000MB/s transfers da2: Command Queueing enabled da2: 61057MB (125045424 512 byte sectors: 255H 63S/T 7783C) (da1:mps0:0:1:0): READ(6). CDB: 08 00 00 02 20 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(10). CDB: 28 00 00 00 01 28 00 01 00 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) # diskinfo -t /dev/da0 /dev/da0 512 # sectorsize 256060514304 # mediasize in bytes (238G) 500118192 # mediasize in sectors 4096 # stripesize 0 # stripeoffset 31130 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 14200C21AE4B # Disk ident. Seek times: Full stroke: 250 iter in 0.091963 sec =3D 0.368 msec Half stroke: 250 iter in 0.084927 sec =3D 0.340 msec Quarter stroke: 500 iter in 0.133857 sec =3D 0.268 msec Short forward: 400 iter in 0.078823 sec =3D 0.197 msec Short backward: 400 iter in 0.081324 sec =3D 0.203 msec Seq outer: 2048 iter in 0.379553 sec =3D 0.185 msec Seq inner: 2048 iter in 0.115075 sec =3D 0.056 msec Transfer rates: outside: 102400 kbytes in 0.491958 sec =3D 208148 kbytes/= sec middle: 102400 kbytes in 0.583785 sec =3D 175407 kbytes/= sec inside: 102400 kbytes in 1.294205 sec =3D 79122 kbytes/= sec # dmesg (da0:mps0:0:0:0): READ(6). CDB: 08 00 07 c1 40 00 length 32768 SMID= 680 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 0c d9 f8 00 length 126976 SMI= D 687 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 1d d1 f8 00 length 126976 SMI= D 707 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 1e c9 f8 00 length 126976 SMI= D 709 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 2c d9 f8 00 length 126976 SMI= D 726 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 2c d9 f8 00 length 126976 SMI= D 727 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 8c d9 f8 00 length 126976 SMI= D 836 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 a8 f9 f8 00 length 126976 SMI= D 869 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 d4 d9 f8 00 length 126976 SMI= D 919 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 e9 f1 f8 00 length 126976 SMI= D 944 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 eb e1 f8 00 length 126976 SMI= D 947 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 00 eb e1 f8 00 length 126976 SMI= D 948 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 00 01 f8 00 length 126976 SMI= D 972 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 31 f1 f8 00 length 126976 SMI= D 66 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 45 d1 f8 00 length 126976 SMI= D 89 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 96 c9 f8 00 length 126976 SMI= D 181 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 a5 d1 f8 00 length 126976 SMI= D 199 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 01 f1 f1 f8 00 length 126976 SMI= D 286 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 70 f9 f8 00 length 126976 SMI= D 430 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 8a e9 f8 00 length 126976 SMI= D 460 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 b0 f9 f8 00 length 126976 SMI= D 504 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(6). CDB: 08 02 eb e1 f8 00 length 126976 SMI= D 571 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 28 20 00 00 f8 00 leng= th 126976 SMID 666 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 2b 48 00 00 f8 00 leng= th 126976 SMID 671 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 53 48 00 00 f8 00 leng= th 126976 SMID 717 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 71 18 00 00 40 00 leng= th 32768 SMID 751 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e6 79 18 00 00 40 00 leng= th 32768 SMID 761 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 50 20 00 00 f8 00 leng= th 126976 SMID 1004 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 5a 50 00 00 f8 00 leng= th 126976 SMID 1017 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 5d 38 00 00 f8 00 leng= th 126976 SMID 1021 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 64 40 00 00 f8 00 leng= th 126976 SMID 67 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 66 30 00 00 f8 00 leng= th 126976 SMID 70 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 6b 48 00 00 f8 00 leng= th 126976 SMID 77 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 89 58 00 00 f8 00 leng= th 126976 SMID 112 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 a0 20 00 00 f8 00 leng= th 126976 SMID 138 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 a2 50 00 00 f8 00 leng= th 126976 SMID 142 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 a2 50 00 00 f8 00 leng= th 126976 SMID 143 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 af 28 00 00 f8 00 leng= th 126976 SMID 158 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e7 c8 20 00 00 f8 00 leng= th 126976 SMID 187 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 10 20 00 00 f8 00 leng= th 126976 SMID 269 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 2d 38 00 00 f8 00 leng= th 126976 SMID 303 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 31 18 00 00 40 00 leng= th 32768 SMID 308 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 3e 30 00 00 f8 00 leng= th 126976 SMID 324 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 83 48 00 00 f8 00 leng= th 126976 SMID 403 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 95 38 00 00 f8 00 leng= th 126976 SMID 424 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 ad 38 00 00 f8 00 leng= th 126976 SMID 452 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 ae 30 00 00 f8 00 leng= th 126976 SMID 454 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e8 dd 38 00 00 f8 00 leng= th 126976 SMID 508 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e9 05 38 00 00 f8 00 leng= th 126976 SMID 554 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e9 09 18 00 00 40 00 leng= th 32768 SMID 559 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 0e e9 09 18 00 00 40 00 leng= th 32768 SMID 560 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 29 78 00 00 f8 00 leng= th 126976 SMID 624 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 31 78 00 00 f8 00 leng= th 126976 SMID 634 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 4a b0 00 00 f8 00 leng= th 126976 SMID 664 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc 85 98 00 00 f8 00 leng= th 126976 SMID 731 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc b3 a8 00 00 f8 00 leng= th 126976 SMID 784 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cc be 90 00 00 f8 00 leng= th 126976 SMID 797 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 22 70 00 00 40 00 leng= th 32768 SMID 910 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 47 88 00 00 f8 00 leng= th 126976 SMID 953 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 53 a8 00 00 f8 00 leng= th 126976 SMID 968 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 65 98 00 00 f8 00 leng= th 126976 SMID 989 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 7a b0 00 00 f8 00 leng= th 126976 SMID 1014 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd 8a 70 00 00 40 00 leng= th 32768 SMID 69 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd a3 a8 00 00 f8 00 leng= th 126976 SMID 98 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd ab a8 00 00 f8 00 leng= th 126976 SMID 109 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd b7 88 00 00 f8 00 leng= th 126976 SMID 123 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cd d2 70 00 00 40 00 leng= th 32768 SMID 154 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 01 78 00 00 f8 00 leng= th 126976 SMID 208 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 16 90 00 00 f8 00 leng= th 126976 SMID 233 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 49 78 00 00 f8 00 leng= th 126976 SMID 291 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 96 90 00 00 f8 00 leng= th 126976 SMID 379 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce 99 78 00 00 f8 00 leng= th 126976 SMID 383 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce a0 80 00 00 f8 00 leng= th 126976 SMID 392 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce af 88 00 00 f8 00 leng= th 126976 SMID 410 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce af 88 00 00 f8 00 leng= th 126976 SMID 411 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce e7 88 00 00 f8 00 leng= th 126976 SMID 475 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce ec a0 00 00 f8 00 leng= th 126976 SMID 482 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce ed 98 00 00 f8 00 leng= th 126976 SMID 484 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d ce f3 a8 00 00 f8 00 leng= th 126976 SMID 492 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cf 12 70 00 00 40 00 leng= th 32768 SMID 527 terminated ioc 804b scsi 0 state 0 xfer 0 (da0:mps0:0:0:0): READ(10). CDB: 28 00 1d cf 1d 98 00 00 f8 00 leng= th 126976 SMID 541 terminated ioc 804b scsi 0 state 0 xfer 0 # diskinfo -t /dev/da1 /dev/da1 512 # sectorsize 64023257088 # mediasize in bytes (60G) 125045424 # mediasize in sectors 0 # stripesize 0 # stripeoffset 7783 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. B492480406 # Disk ident. Seek times: Full stroke: 250 iter in 0.041779 sec =3D 0.167 msec Half stroke: 250 iter in 0.034729 sec =3D 0.139 msec Quarter stroke: 500 iter in 0.083738 sec =3D 0.167 msec Short forward: 400 iter in 0.066829 sec =3D 0.167 msec Short backward: 400 iter in 0.091763 sec =3D 0.229 msec Seq outer: 2048 iter in 0.346279 sec =3D 0.169 msec Seq inner: 2048 iter in 0.137749 sec =3D 0.067 msec Transfer rates: outside: 102400 kbytes in 0.318925 sec =3D 321079 kbytes/= sec middle: 102400 kbytes in 0.255251 sec =3D 401174 kbytes/= sec inside: 102400 kbytes in 0.259874 sec =3D 394037 kbytes/= sec # dmesg (da1:mps0:0:1:0): READ(6). CDB: 08 00 95 d1 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 00 bd d1 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 00 dc d9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 01 2c d9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 01 49 f1 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 67 c1 40 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 97 c1 40 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 a4 d9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 02 d6 c9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) (da1:mps0:0:1:0): READ(6). CDB: 08 03 02 e9 f8 00 (da1:mps0:0:1:0): CAM status: SCSI Status Error (da1:mps0:0:1:0): SCSI status: Check Condition (da1:mps0:0:1:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da1:mps0:0:1:0): Retrying command (per sense data) diskinfo -t /dev/da2 /dev/da2 512 # sectorsize 64023257088 # mediasize in bytes (60G) 125045424 # mediasize in sectors 0 # stripesize 0 # stripeoffset 7783 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. B492480446 # Disk ident. Seek times: Full stroke: 250 iter in 0.102417 sec =3D 0.410 msec Half stroke: 250 iter in 0.126357 sec =3D 0.505 msec Quarter stroke: 500 iter in 0.243542 sec =3D 0.487 msec Short forward: 400 iter in 0.046180 sec =3D 0.115 msec Short backward: 400 iter in 0.052594 sec =3D 0.131 msec Seq outer: 2048 iter in 0.262600 sec =3D 0.128 msec Seq inner: 2048 iter in 0.228124 sec =3D 0.111 msec Transfer rates: outside: 102400 kbytes in 0.378072 sec =3D 270848 kbytes/= sec middle: 102400 kbytes in 0.314390 sec =3D 325710 kbytes/= sec inside: 102400 kbytes in 0.348791 sec =3D 293586 kbytes/= sec # dmesg (da2:mps0:0:2:0): READ(6). CDB: 08 00 98 f9 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 00 bd d1 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 01 3f c1 40 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 01 a5 d1 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) (da2:mps0:0:2:0): READ(6). CDB: 08 03 05 d1 f8 00 (da2:mps0:0:2:0): CAM status: SCSI Status Error (da2:mps0:0:2:0): SCSI status: Check Condition (da2:mps0:0:2:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iu= CRC error detected) (da2:mps0:0:2:0): Retrying command (per sense data) -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E= 800 _______________________________________________ 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" GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 22:11:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11957AAA for ; Sun, 16 Nov 2014 22:11:51 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C18A8F6 for ; Sun, 16 Nov 2014 22:11:50 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xq82x-000Dnh-Bf for freebsd-stable@freebsd.org; Sun, 16 Nov 2014 23:11:51 +0100 Date: Sun, 16 Nov 2014 23:11:51 +0100 From: Kurt Jaeger To: freebsd-stable@freebsd.org Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <20141116221151.GG44537@home.opsec.eu> References: <20141116213910.GF44537@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141116213910.GF44537@home.opsec.eu> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 22:11:51 -0000 Hi! > The raid controller: Adaptec 6405E Replacing it with an Adaptec ASR8405 and the drives are back alive. Any ideas why this happens ? That behaviour is very unexpected. aacraid0: port 0xb000-0xb0ff mem 0xf7400000-0xf74fffff,0xf7580000-0xf75803ff irq 16 at device 0.0 on pci6 aacraid0: Enable Raw I/O aacraid0: Enable 64-bit array aacraid0: using MSI-X interrupts (32 vectors) aacraid0: New comm. interface type2 enabled aacraid0: ASR8405, aacraid driver 3.2.5-1 aacraidp0 on aacraid0 aacraidp1 on aacraid0 aacraidp2 on aacraid0 aacraidp3 on aacraid0 da0 at aacraidp1 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SCSI-6 device da0: Serial Number PK1B31P8H5DD2V da0: 300.000MB/s transfers da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da1 at aacraidp1 bus 0 scbus1 target 1 lun 0 da1: Fixed Direct Access SCSI-6 device da1: Serial Number PK1B31P8H5L97P da1: 300.000MB/s transfers da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 22:30:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 796D2F5A for ; Sun, 16 Nov 2014 22:30:42 +0000 (UTC) Received: from nagini.codelibre.net (nagini.codelibre.net [IPv6:2001:41c8:1:5750::2]) by mx1.freebsd.org (Postfix) with ESMTP id 43E9A1FF for ; Sun, 16 Nov 2014 22:30:42 +0000 (UTC) Received: by nagini.codelibre.net (Postfix, from userid 1000) id 76E8D182E1; Sun, 16 Nov 2014 22:30:41 +0000 (GMT) Date: Sun, 16 Nov 2014 22:30:41 +0000 From: Roger Leigh To: freebsd-stable@freebsd.org Subject: Re: PCI-E SATA-III HBA for FreeBSD 10 Message-ID: <20141116223041.GN1657@codelibre.net> References: <20140817171554.GB7997@codelibre.net> <20140822101014.GE7997@codelibre.net> <20141116211316.GM1657@codelibre.net> <9C91F97841BC4347910F206618BAA3BBA3692AB8@PAIMAIL.pai.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C91F97841BC4347910F206618BAA3BBA3692AB8@PAIMAIL.pai.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 22:30:42 -0000 On Sun, Nov 16, 2014 at 04:36:08PM -0500, Michael Jung wrote: > Roger, > > Try P19 firmware in IT mode. I just moved a bunch of drives to 9211-8i's and had similar problems with P20 firmware. > > Downgrading to P19 resolved the issue for me. > > I would have posted to the list like you but the server changes were in the middle of the night and I needed a quick resolution. Ah, I can try that, thanks. Did you have to do anything special to downgrade? When I run sas2flsh (from a DOS USB drive), I get (with sas2flsh -o -f 2114it.bin -b mptsas2.rom): Cannot downgrade NVDATA version 14.00.00.06 to 11.00.110000.00. Are you selectively updating just 2114it.bin or mptsas2.rom? Or mixing and matching one from P19 and one from P20? Sorry if this is really obvious, but this is the first LSI HBA I've used. Managed to flash P20 OK, but downgrading seems trickier! Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 23:11:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60528AB3 for ; Sun, 16 Nov 2014 23:11:52 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21B0688B for ; Sun, 16 Nov 2014 23:11:51 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id sAGNBmZR016008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Nov 2014 18:11:48 -0500 (EST) (envelope-from mikej@paymentallianceintl.com) Received: from PAICAS.pai.local (10.10.0.154) by PAIMAIL.pai.local (10.10.0.153) with Microsoft SMTP Server (TLS) id 8.3.377.0; Sun, 16 Nov 2014 18:11:48 -0500 Received: from PAIMAIL.pai.local ([::1]) by PAICAS.pai.local ([::1]) with mapi; Sun, 16 Nov 2014 18:11:47 -0500 From: Michael Jung To: Roger Leigh , "freebsd-stable@freebsd.org" Date: Sun, 16 Nov 2014 18:11:46 -0500 Subject: RE: PCI-E SATA-III HBA for FreeBSD 10 Thread-Topic: PCI-E SATA-III HBA for FreeBSD 10 Thread-Index: AdAB7PrNTBIrzH6aS662hfaFZzi+sQABCFdu Message-ID: <9C91F97841BC4347910F206618BAA3BBA3692AB9@PAIMAIL.pai.local> References: <20140817171554.GB7997@codelibre.net> <20140822101014.GE7997@codelibre.net> <20141116211316.GM1657@codelibre.net> <9C91F97841BC4347910F206618BAA3BBA3692AB8@PAIMAIL.pai.local>, <20141116223041.GN1657@codelibre.net> In-Reply-To: <20141116223041.GN1657@codelibre.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 23:11:52 -0000 Roger, I downgraded several different controllers on two different motherboards an= d=20 the procedure was the same other than on a SuperMicro motherboard I=20 used the .efi version of the sas2flsh binary and the on the other motherboa= rds=20 used the regular MSDOS sas2flsh binary under FreeDOS booted from USB. In both cases I used the sasl2flsh binary that came with the P20 firmware b= ut used the .bin and .rom files from the P19 zip file. Using the P20 sasl2fls= h=20 binary may be difference. I did not try the P19 binary to downgrade. >From my notes to downgrade I simply: sas2flsh -o -e6 sas2flsh -f .bin -b .rom The .bin and .rom files were from the unpacked P19 zip file. You can issue sas2flsh -listall after the downgrade and you should see that P19 was installed on the contro= ller. I have also downgraded 9212-4e4i cards like this from P20 My home machine which has a 9211-8i and 9212-4e4i looks like then in dmesg = running P19 mps0: port 0x5000-0x50ff mem 0xfd3fc000-0xfd3fffff,0xfd380000= -0xfd3bffff irq 19 at device 0.0 on pci11 mps0: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbsd mps0: IOCCapabilities: 1285c mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: attempting to allocate 1 MSI vectors (1 supported) mps0: using IRQ 257 for MSI mps1: port 0x6000-0x60ff mem 0xfd2fc000-0xfd2fffff,0xfd280000= -0xfd2bffff irq 16 at device 0.0 on pci19 mps1: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbsd mps1: IOCCapabilities: 1285c mps1: attempting to allocate 1 MSI-X vectors (15 supported) mps1: attempting to allocate 1 MSI vectors (1 supported) mps1: using IRQ 258 for MSI I'm running FreeBSD 10.1-BETA3 #0 r272215: at home and using the cards with= ZFS - they work well. --mikej ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] O= n Behalf Of Roger Leigh [rleigh@codelibre.net] Sent: Sunday, November 16, 2014 5:30 PM To: freebsd-stable@freebsd.org Subject: Re: PCI-E SATA-III HBA for FreeBSD 10 On Sun, Nov 16, 2014 at 04:36:08PM -0500, Michael Jung wrote: > Roger, > > Try P19 firmware in IT mode. I just moved a bunch of drives to 9211-8i's= and had similar problems with P20 firmware. > > Downgrading to P19 resolved the issue for me. > > I would have posted to the list like you but the server changes were in t= he middle of the night and I needed a quick resolution. Ah, I can try that, thanks. Did you have to do anything special to downgrade? When I run sas2flsh (from a DOS USB drive), I get (with sas2flsh -o -f 2114it.bin -b mptsas2.rom): Cannot downgrade NVDATA version 14.00.00.06 to 11.00.110000.00. Are you selectively updating just 2114it.bin or mptsas2.rom? Or mixing and matching one from P19 and one from P20? Sorry if this is really obvious, but this is the first LSI HBA I've used. Managed to flash P20 OK, but downgrading seems trickier! Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E= 800 _______________________________________________ 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"= =0A= GoPai.com | Facebook.com/PaymentAlliance =20 CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may=20 contain information that is privileged, confidential, and=20 exempt from disclosure under applicable law. If the reader=20 of this message is not the intended recipient, you are hereby=20 notified that any dissemination, distribution or copying=20 of this communication is strictly prohibited. If you have=20 received this transmission in error, please notify us by=20 telephone at (502) 212-4001 or notify us at PAI , Dept. 99,=20 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 23:15:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9E7DBBA for ; Sun, 16 Nov 2014 23:15:12 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EDBB8A7 for ; Sun, 16 Nov 2014 23:15:12 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id uy5so2465317obc.32 for ; Sun, 16 Nov 2014 15:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8wGBkxM/drPI7TOo/hp063mmwRX70Ee2f4/kP+RHyhA=; b=n9RO/UXbz8JsrTd0F+RC3p9+OHmcogK7s3xaLU8O94216cpGP5bTtxTx1CFV9RIwFy eAKPYXQE9x4/MXhKcbobSj7pJ/ureUnuCfTauqu8ZRGcKtMB7NfwSmYRjw5F89BcR/xe JjdyagJUQcKQaAX6NnSQ+XDFpaWaZ9I5bkOGCuovjnfCg0qnxN7R8XaEDWbKF1Ajg5tC YKYG6ZJJU3BSZf7d70CEUyumok6moyX1Qnf73E316gePa72Wlgz0cCsyscwN2hJbijHR kRz6C6dBrEGZtl7X+O1BZspxQ7jDtKwZ7r1j63FlcN8wEYl7ZENYWPKZiIfdx05l4OPK ew8A== MIME-Version: 1.0 X-Received: by 10.202.87.212 with SMTP id l203mr20056131oib.36.1416179711714; Sun, 16 Nov 2014 15:15:11 -0800 (PST) Received: by 10.182.171.73 with HTTP; Sun, 16 Nov 2014 15:15:11 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Nov 2014 15:15:11 -0800 Message-ID: Subject: Re: cvmx-srio.c From: jungle Boogie To: freebsd-stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 23:15:12 -0000 UPDATE: everything it fine, I went with a higher end VM and 10-stable processed as expected: 2252.540u 348.640s 16:41.00 259.8% 7579+976k 35183+56561io 7475pf+0w Even 11-current built without any issues. Not bad for $1! Thanks all, j.b. On 16 November 2014 01:06, jungle Boogie wrote: > Hello All, > > You may be aware of the Edge Router Lite[0] (ERL) and that it can run > FreeBSD in place of the GNU/Linux/Debian kernel, OS, etc that it comes > standard with. > > Well a cool FreeBSD guy, Nathan Dorfman, created a script that allows > you to build a freeBSD image that you can run on your ERL. The only > caveat is that you need to be running a freeBSD that you want to also > run on the ERL. > > The other day I had my 10-stable machine spend about two days making > the image with Nathan's script[1]. > > # uname -a > FreeBSD pulse 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r274439: Wed > Nov 12 15:07:52 PST 2014 root@pulse:/usr/obj/usr/src/sys/GENERIC > i386 > > New VM: > # uname -a > FreeBSD build 10.1-STABLE FreeBSD 10.1-STABLE #0 r274578: Sat Nov 15 > 23:55:08 PST 2014 root@build:/usr/obj/usr/src/sys/GENERIC amd64 > > > > Thanks, > jb > > [0] http://www.ubnt.com/edgemax/edgerouter-lite/ > [1] http://rtfm.net/FreeBSD/ERL/mkerlimage > > > -- > ------- > inum: 883510009027723 > sip: jungleboogie@sip2sip.info > xmpp: jungle-boogie@jit.si -- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-stable@FreeBSD.ORG Sun Nov 16 23:16:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72AE9D54 for ; Sun, 16 Nov 2014 23:16:40 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45FA38C6 for ; Sun, 16 Nov 2014 23:16:40 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id sAGNGbm7016194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Nov 2014 18:16:37 -0500 (EST) (envelope-from mikej@paymentallianceintl.com) Received: from PAIMAIL.pai.local ([::1]) by PAIMAIL.pai.local ([::1]) with mapi; Sun, 16 Nov 2014 18:16:37 -0500 From: Michael Jung To: Michael Jung , Roger Leigh , "freebsd-stable@freebsd.org" Date: Sun, 16 Nov 2014 18:16:02 -0500 Subject: RE: PCI-E SATA-III HBA for FreeBSD 10 Thread-Topic: PCI-E SATA-III HBA for FreeBSD 10 Thread-Index: AdAB7PrNTBIrzH6aS662hfaFZzi+sQABCFduAACLiJg= Message-ID: <9C91F97841BC4347910F206618BAA3BBA3692ABA@PAIMAIL.pai.local> References: <20140817171554.GB7997@codelibre.net> <20140822101014.GE7997@codelibre.net> <20141116211316.GM1657@codelibre.net> <9C91F97841BC4347910F206618BAA3BBA3692AB8@PAIMAIL.pai.local>, <20141116223041.GN1657@codelibre.net>, <9C91F97841BC4347910F206618BAA3BBA3692AB9@PAIMAIL.pai.local> In-Reply-To: <9C91F97841BC4347910F206618BAA3BBA3692AB9@PAIMAIL.pai.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 16 Nov 2014 23:16:40 -0000 That should be sas2flsh -o -f .bin -b .rom - don't forget the "-= o" ! --mikej ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] O= n Behalf Of Michael Jung [mikej@paymentallianceintl.com] Sent: Sunday, November 16, 2014 6:11 PM To: Roger Leigh; freebsd-stable@freebsd.org Subject: RE: PCI-E SATA-III HBA for FreeBSD 10 Roger, I downgraded several different controllers on two different motherboards an= d the procedure was the same other than on a SuperMicro motherboard I used the .efi version of the sas2flsh binary and the on the other motherboa= rds used the regular MSDOS sas2flsh binary under FreeDOS booted from USB. In both cases I used the sasl2flsh binary that came with the P20 firmware b= ut used the .bin and .rom files from the P19 zip file. Using the P20 sasl2fls= h binary may be difference. I did not try the P19 binary to downgrade. >From my notes to downgrade I simply: sas2flsh -o -e6 sas2flsh -f .bin -b .rom The .bin and .rom files were from the unpacked P19 zip file. You can issue sas2flsh -listall after the downgrade and you should see that P19 was installed on the contro= ller. I have also downgraded 9212-4e4i cards like this from P20 My home machine which has a 9211-8i and 9212-4e4i looks like then in dmesg = running P19 mps0: port 0x5000-0x50ff mem 0xfd3fc000-0xfd3fffff,0xfd380000= -0xfd3bffff irq 19 at device 0.0 on pci11 mps0: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbsd mps0: IOCCapabilities: 1285c mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: attempting to allocate 1 MSI vectors (1 supported) mps0: using IRQ 257 for MSI mps1: port 0x6000-0x60ff mem 0xfd2fc000-0xfd2fffff,0xfd280000= -0xfd2bffff irq 16 at device 0.0 on pci19 mps1: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbsd mps1: IOCCapabilities: 1285c mps1: attempting to allocate 1 MSI-X vectors (15 supported) mps1: attempting to allocate 1 MSI vectors (1 supported) mps1: using IRQ 258 for MSI I'm running FreeBSD 10.1-BETA3 #0 r272215: at home and using the cards with= ZFS - they work well. --mikej ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] O= n Behalf Of Roger Leigh [rleigh@codelibre.net] Sent: Sunday, November 16, 2014 5:30 PM To: freebsd-stable@freebsd.org Subject: Re: PCI-E SATA-III HBA for FreeBSD 10 On Sun, Nov 16, 2014 at 04:36:08PM -0500, Michael Jung wrote: > Roger, > > Try P19 firmware in IT mode. I just moved a bunch of drives to 9211-8i's= and had similar problems with P20 firmware. > > Downgrading to P19 resolved the issue for me. > > I would have posted to the list like you but the server changes were in t= he middle of the night and I needed a quick resolution. Ah, I can try that, thanks. Did you have to do anything special to downgrade? When I run sas2flsh (from a DOS USB drive), I get (with sas2flsh -o -f 2114it.bin -b mptsas2.rom): Cannot downgrade NVDATA version 14.00.00.06 to 11.00.110000.00. Are you selectively updating just 2114it.bin or mptsas2.rom? Or mixing and matching one from P19 and one from P20? Sorry if this is really obvious, but this is the first LSI HBA I've used. Managed to flash P20 OK, but downgrading seems trickier! Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E= 800 _______________________________________________ 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" GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 _______________________________________________ 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" GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 00:18:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFFBCFD1 for ; Mon, 17 Nov 2014 00:18:32 +0000 (UTC) Received: from nagini.codelibre.net (nagini.codelibre.net [IPv6:2001:41c8:1:5750::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99C76E33 for ; Mon, 17 Nov 2014 00:18:32 +0000 (UTC) Received: by nagini.codelibre.net (Postfix, from userid 1000) id D3E48182E1; Mon, 17 Nov 2014 00:18:31 +0000 (GMT) Date: Mon, 17 Nov 2014 00:18:31 +0000 From: Roger Leigh To: freebsd-stable@freebsd.org Subject: Re: PCI-E SATA-III HBA for FreeBSD 10 Message-ID: <20141117001831.GO1657@codelibre.net> References: <20140817171554.GB7997@codelibre.net> <20140822101014.GE7997@codelibre.net> <20141116211316.GM1657@codelibre.net> <9C91F97841BC4347910F206618BAA3BBA3692AB8@PAIMAIL.pai.local> <20141116223041.GN1657@codelibre.net> <9C91F97841BC4347910F206618BAA3BBA3692AB9@PAIMAIL.pai.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C91F97841BC4347910F206618BAA3BBA3692AB9@PAIMAIL.pai.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 00:18:32 -0000 On Sun, Nov 16, 2014 at 06:11:46PM -0500, Michael Jung wrote: > Roger, > > I downgraded several different controllers on two different motherboards and > the procedure was the same other than on a SuperMicro motherboard I > used the .efi version of the sas2flsh binary and the on the other motherboards > used the regular MSDOS sas2flsh binary under FreeDOS booted from USB. > > In both cases I used the sasl2flsh binary that came with the P20 firmware but > used the .bin and .rom files from the P19 zip file. Using the P20 sasl2flsh > binary may be difference. I did not try the P19 binary to downgrade. > > From my notes to downgrade I simply: > > sas2flsh -o -e6 > > sas2flsh -f .bin -b .rom Thanks, I was missing the flash erase step because it seemed unnecessarily scary! The downgrade then worked just fine. After rebooting into FreeBSD I can confirm repeating the "diskinfo -t" tests that all the errors have now gone. I'll do some more extensive testing tomorrow, but it looks like this has solved the problem. Should be ready to put into use as discs for ZIL, L2ARC and the base system. Thank you very much for your help, which was very much appreciated! Kind regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 02:48:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02986F6A; Mon, 17 Nov 2014 02:48:23 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 977A7D14; Mon, 17 Nov 2014 02:48:22 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id sAH2cLdt062440; Mon, 17 Nov 2014 02:38:21 GMT (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id sAH2cLXQ062439; Mon, 17 Nov 2014 02:38:21 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201411170238.sAH2cLXQ062439@dyslexicfish.net> Date: Mon, 17 Nov 2014 02:38:21 +0000 To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Potential security issues with new top level domains? User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [91.109.5.35]); Mon, 17 Nov 2014 02:38:21 +0000 (GMT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 02:48:23 -0000 As if I needed another reason to hate the new top level domain free-for-all, I was checking on one of my machines earlier, and forgot that I'd renamed it, so it is no longer in my domains DNS. This was the result: | 2:13 (2) "~" jamie@catflap% ping android | PING android (127.0.53.53): 56 data bytes | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ^C | --- android ping statistics --- | 3 packets transmitted, 0 packets received, 100.0% packet loss | | 2:13 (3) "~" jamie@catflap% cat /etc/resolv.conf | domain dyslexicfish.net | nameserver 127.0.0.1 | options edns0 A quick check revealed that, as expected, unbound was first asked for 'android.dyslexicfish.net.' which returned NX, and was then asked for 'android.' which resolved the 'A' that the owners of the TLD have configured. Now, any scripts/binaries etc. I have that use DNS resolution always use the FQDN with the trailing dot, so I have no personal security worries, but I'm sure there are others out there that don't, and even so, it could still bite for interactive use. Yes, the 'A' returned is invalid in this case, but what's to say this will be the case with all future new TLDs? I realise the spec is being followed correctly, but it still seems wrong to me that any 'host' related resource types resolve for an address at the top level, and I was wondering what others thought about it? Should the FreeBSD resolver ignore / not make such requests? Should instead the functionality be built into unbound/named etc.? Should instead TLD owners be banned from adding such records? (this still could be abused though) Should neither be done? I dunno, I'm just used to A/AAAA resolves on a non qualified address to either come from /etc/hosts, or be in under a domain in 'domain/search' from /etc/resolv.conf The current situation seems 'wrong' and potentially troublesome to me, but I'd be interested in what others think. Cheers, Jamie From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 03:18:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C8D7C04; Mon, 17 Nov 2014 03:18:39 +0000 (UTC) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73970DE; Mon, 17 Nov 2014 03:18:38 +0000 (UTC) Received: from [10.20.30.90] (142-254-17-111.dsl.dynamic.fusionbroadband.com [142.254.17.111]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sAH3INNB056185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2014 20:18:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-111.dsl.dynamic.fusionbroadband.com [142.254.17.111] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Potential security issues with new top level domains? From: Paul Hoffman In-Reply-To: <201411170238.sAH2cLXQ062439@dyslexicfish.net> Date: Sun, 16 Nov 2014 19:18:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9848F63A-D88F-4A8A-A15B-E2B5D4A5939C@vpnc.org> References: <201411170238.sAH2cLXQ062439@dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 03:18:39 -0000 On Nov 16, 2014, at 6:38 PM, Jamie Landeg-Jones = wrote: > Yes, the 'A' returned is invalid in this case, but what's to say this > will be the case with all future new TLDs? It will be the case for the first 90 days for all new TLDs that have = three or more letters in their names; it will probably not be true for = new TLDs with two letters in their name. > I realise the spec is being followed correctly, Yes. > but it still seems wrong > to me that any 'host' related resource types resolve for an address at = the > top level, and I was wondering what others thought about it? The spec is being followed correctly, and there are many other TLDs that = do this: see . > Should the FreeBSD resolver ignore / not make such requests? >=20 > Should instead the functionality be built into unbound/named etc.? >=20 > Should instead TLD owners be banned from adding such records? (this = still > could be abused though) No, no, and no. As you say above, the spec is being followed. You can = mitigate your misuse of the DNS: = . --Paul Hoffman (a long-time FreeBSDer who co-wrote the above RFC, and also wrote the = ICANN report)= From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 08:56:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC7C0CC5 for ; Mon, 17 Nov 2014 08:56:10 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8503E5F1 for ; Mon, 17 Nov 2014 08:56:10 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so1834159wiv.6 for ; Mon, 17 Nov 2014 00:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lD3vfLNT67PrhQ80pgj3PGeCDYsRYQXraFCq4rbrz4w=; b=cUlXZeCQupfg0KuDxdR+yQIHfapLhVxZrARA9oQ6Ck6UCT/lzg++tEXsS62rRjwtHD XXUX2M7pVhXnjkW09hHTxcfDezgv2EhGCUiEqKMfqyOMkDVXR3xag5WQFbQuiuraSznj yl3lTZeIcwqgJeuLwDD8O/7Z5vzo8h2jUqiDBiNYIsXi73HtCLchGCQThASVW3qyF/oj 81Wz3Yi/Zpn0MakdoL6p9K7BmPkZq/9ghPFsy3S54hTsx3cxMvJDTRjwo35fHn8e7EYU KitfAq+zdGikuR5H0hCLzA61LR1G0PapSV62ZAHH81tOXBVkk9UiF+URjejR9yiuKOdF J9UQ== X-Received: by 10.194.249.70 with SMTP id ys6mr3087495wjc.61.1416214567673; Mon, 17 Nov 2014 00:56:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.151.233 with HTTP; Mon, 17 Nov 2014 00:55:27 -0800 (PST) In-Reply-To: References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> From: Bogdan SOLGA Date: Mon, 17 Nov 2014 10:55:27 +0200 Message-ID: Subject: Re: ZFS pool creation from files leads to a crash To: Christer Solskogen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 08:56:11 -0000 Thank you, Christer! 'vfs.zfs.trim.enabled=0' solved the issue in the VMs. Will there be a fix for SSD based ZFS pools, as well? Kind regards, Bogdan On Sun, Nov 16, 2014 at 11:34 PM, Christer Solskogen < christer.solskogen@gmail.com> wrote: > On 16.11.2014 22:08, K. Macy wrote: > > Do you somehow have TRIM disabled? >> >> > Confirmed on real hw (that don't have any SSD's). > With vfs.zfs.trim.enabled=0 there is no kernel panic. > vfs.zfs.trim.enabled=1 will make it panic. > > -- > chs > > From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 10:48:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2219F610 for ; Mon, 17 Nov 2014 10:48:11 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A598CFE for ; Mon, 17 Nov 2014 10:48:10 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x13so24298454wgg.22 for ; Mon, 17 Nov 2014 02:48:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qyBhgTpvpf2v93q5EZwtEc7AFBynUfxVDWC9NfEocrg=; b=d0gKYxb7cu894hU7xqEiK6+HMYPck34bStwR2tkPyOZCLyEpzIMOscJFnfNjteQQV/ mziJBWjZyyzqo/NhIjwGKDFXmkGtsR37D/2GFBV9xZsOYfgsL9QX6Z8TWCMQrkp795HX OLCIbLdnCNn6fmzfSiW9YL9bGwxe0at/iE7TwbjHx1Bsw2xaI+kDY8+0uM3+nwtCKBPx FnUAfhlQgQEN/AlHjTSBwapsCjY8AvjqIXApPQLkQQenURPq65evIsWcF57EinecNoYr U9CXAN9a0jgxIKvFGvIo7ZPwDYgih7os0/0kheNCpoHMJs6hdQIBSfKZzXUo/4+yzOh/ rKAg== X-Gm-Message-State: ALoCoQmwKh51NLmPmJi9OvupkMtxxcnSxGgA7goFZEzzKTDclgrcHw8f61/yItgorRLsirZR6LTI X-Received: by 10.194.89.129 with SMTP id bo1mr37943663wjb.29.1416221282477; Mon, 17 Nov 2014 02:48:02 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ft8sm28062838wjb.17.2014.11.17.02.48.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 02:48:00 -0800 (PST) Message-ID: <5469D263.8040503@multiplay.co.uk> Date: Mon, 17 Nov 2014 10:48:03 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "K. Macy" Subject: Re: ZFS pool creation from files leads to a crash References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 10:48:11 -0000 On 16/11/2014 21:08, K. Macy wrote: > On Sun, Nov 16, 2014 at 8:15 AM, Steven Hartland > wrote: >> It is indeed see the following bug for breakdown and patch: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 I'd love to >> know why I can run this many times over here and not a single sign of >> a panic :( > > Do you somehow have TRIM disabled? > > -K I didn't have TRIM disabled via vfs.zfs.trim.enabled, but turns out I did have trim vfs.zfs.vdev.trim_on_init disabled which is why I wasn't seeing it on pool creation. I'll be committing a fix for this shortly. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 12:53:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEF16F04 for ; Mon, 17 Nov 2014 12:53:34 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 238622F for ; Mon, 17 Nov 2014 12:53:33 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id f15so17142366lbj.41 for ; Mon, 17 Nov 2014 04:53:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wZJK+OqIx/JuPXaKkEYNjIxy4n+PZe1IMlwNlOPbv2U=; b=TgUh5aMs6Z4+544XX4Y47FdEYCOtTRjx0ILFuADIzek7c0DivIGRABNkcbG8yrFQFP R/KzOo9lAfRINaxQecIMfJ/RAcPAcLJOkRRnOFAo+awwOv4/1ZF+C8r7zro2qUzu6nvY S2Ol4pSVxSetHYpoVpvKS1DXHe8Mf3l4axRT3UgX6Sz2zGSJfD9SyleUGrWdrcfPRyjJ 5w0dx1Di5g5E6BdxhCQzmDFZS15BeRq62JtU5HQYzZHxahVNaHn6RxJSXYR6uQZy3GXh G1WJNS5YQSQBt0VggOb/qDqroZn5kfvrSXtkapo39D9gxp75SVk7Cpn47T9r7zO4eB1M 5Rkw== X-Gm-Message-State: ALoCoQmYNUWg1R7sx8ZNN10XwxOLkP6WCk55rFbNsrzbXezlxwgHucXZW7XBzD3qFvxpgu1rKBkz X-Received: by 10.112.141.104 with SMTP id rn8mr9950135lbb.87.1416228811479; Mon, 17 Nov 2014 04:53:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.1 with HTTP; Mon, 17 Nov 2014 04:53:01 -0800 (PST) In-Reply-To: <20141116213910.GF44537@home.opsec.eu> References: <20141116213910.GF44537@home.opsec.eu> From: Steven Hartland Date: Mon, 17 Nov 2014 12:53:01 +0000 Message-ID: Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? To: Kurt Jaeger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 12:53:34 -0000 If your running a custom kernel do you have both the options for aac enable: device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device aacraid # Adaptec by PMC RAID If you're missing aacp then you might get the behaviour your seeing. On 16 November 2014 21:39, Kurt Jaeger wrote: > Hi! > > Under 10.0, we had: > > da0 at aacraidp1 bus 0 scbus1 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > (offline) > da0: Serial Number PK1B31P8H5DD2V > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da1 at aacraidp1 bus 0 scbus1 target 1 lun 0 > da1: Fixed Direct Access SCSI-5 device > (offline) > da1: Serial Number PK1B31P8H5L97P > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > > Under 10.1, we have: > > pass0 at aacraidp1 bus 0 scbus1 target 0 lun 0 > pass0: Fixed unknown SCSI-5 device (offline) > pass0: Serial Number PK1B31P8H5DD2V > pass0: 300.000MB/s transfers > pass0: Command Queueing enabled > pass1 at aacraidp1 bus 0 scbus1 target 1 lun 0 > pass1: Fixed unknown SCSI-5 device (offline) > pass1: Serial Number PK1B31P8H5L97P > pass1: 300.000MB/s transfers > pass1: Command Queueing enabled > > The raid controller: Adaptec 6405E > > aacraid0: mem > 0xf7400000-0xf77fffff,0xf7841000-0xf78417ff,0xf7840000-0xf78400ff irq 17 at > device 0.0 on pci2 > aacraid0: Enable Raw I/O > aacraid0: Enable 64-bit array > aacraid0: New comm. interface type1 enabled > aacraid0: Adaptec 6405E, aacraid driver 3.2.5-1 > aacraidp0 on aacraid0 > aacraidp1 on aacraid0 > aacraidp2 on aacraid0 > aacraidp3 on aacraid0 > > How do I tell the controller to start those drives and make > them visible again ? > > -- > pi@opsec.eu +49 171 3101372 6 years to > go ! > _______________________________________________ > 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 Mon Nov 17 14:02:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB1C65E8 for ; Mon, 17 Nov 2014 14:02:03 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CACCA03 for ; Mon, 17 Nov 2014 14:02:02 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so3131952wib.5 for ; Mon, 17 Nov 2014 06:01:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bnr107CdIWmRUxQYJWK953AczspOf1UrCxlUSNhvrFg=; b=BrW79Epc6L5jDKx9YlJXEd4hmJi4vCA3UzEiuJtxEYWNNT2/IFPVyxGSMQMukJI2IX 5e1+SiwGUE0sTsrn+Z91lOBEjWhQHwH8t71CbVVOGsqPYIUAwB/ZcuGavrJGAw6SOSn7 BiUvNbNiafLvzjipw5JViae+dmKoDf1GMhuX2cYzfW4UzmjfN8eHIKuUiYUmlJuxfZ83 00Da0hTQ1K9sJ/WXCAQ7JXIkWyaMutBY8RqKVhCh8nohHbLDTgEEADzgDizPDMTQfh9+ uaPcO6TPPLODz//c5RrdB3U8JQFazUf3lznE6bsomif+hvepuJSMzW/oOk/ey1NCz8UY D3yQ== X-Gm-Message-State: ALoCoQnv2ThMJG8KSbYkoKB/8BXH2HTt49mKi0WPjZ+KGf3MjHFwwegm570hkpIpGQnHwSlfzD/C X-Received: by 10.180.109.3 with SMTP id ho3mr26395758wib.39.1416232914457; Mon, 17 Nov 2014 06:01:54 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id el6sm15353096wib.23.2014.11.17.06.01.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 06:01:53 -0800 (PST) Message-ID: <5469FFD5.9070002@multiplay.co.uk> Date: Mon, 17 Nov 2014 14:01:57 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bogdan SOLGA , Christer Solskogen Subject: Re: ZFS pool creation from files leads to a crash References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 14:02:04 -0000 I committed the fix for this earlier: https://svnweb.freebsd.org/changeset/base/274619 On 17/11/2014 08:55, Bogdan SOLGA wrote: > Thank you, Christer! 'vfs.zfs.trim.enabled=0' solved the issue in the VMs. > > Will there be a fix for SSD based ZFS pools, as well? > > Kind regards, > Bogdan > > On Sun, Nov 16, 2014 at 11:34 PM, Christer Solskogen < > christer.solskogen@gmail.com> wrote: > >> On 16.11.2014 22:08, K. Macy wrote: >> >> Do you somehow have TRIM disabled? >>> >> Confirmed on real hw (that don't have any SSD's). >> With vfs.zfs.trim.enabled=0 there is no kernel panic. >> vfs.zfs.trim.enabled=1 will make it panic. >> >> -- >> chs >> >> > _______________________________________________ > 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 Mon Nov 17 14:33:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D81F5F08 for ; Mon, 17 Nov 2014 14:33:28 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91FECD40 for ; Mon, 17 Nov 2014 14:33:28 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XqNMp-000G1Y-So; Mon, 17 Nov 2014 15:33:23 +0100 Date: Mon, 17 Nov 2014 15:33:23 +0100 From: Kurt Jaeger To: Steven Hartland Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <20141117143323.GH44537@home.opsec.eu> References: <20141116213910.GF44537@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Kurt Jaeger , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 14:33:28 -0000 Hi! > If your running a custom kernel do you have both the options for aac enable: It's the GENERIC kernel. -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 14:37:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8197C267 for ; Mon, 17 Nov 2014 14:37:12 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E6AED7F for ; Mon, 17 Nov 2014 14:37:11 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 82E269DE154; Mon, 17 Nov 2014 15:37:07 +0100 (CET) Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20141117143323.GH44537@home.opsec.eu> Date: Mon, 17 Nov 2014 15:37:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> To: Kurt Jaeger X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Stable , Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 14:37:12 -0000 On Nov 17, 2014, at 3:33 PM, Kurt Jaeger wrote: > Hi! >=20 >> If your running a custom kernel do you have both the options for aac = enable: >=20 > It's the GENERIC kernel. That's curious. In order to have direct access to the disks I had to = patch aac_cam.c. Maybe you were using a patched file and you forgot? Borja. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 14:50:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05CD0898 for ; Mon, 17 Nov 2014 14:50:49 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F51CF37 for ; Mon, 17 Nov 2014 14:50:48 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l15so6011277wiw.2 for ; Mon, 17 Nov 2014 06:50:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l/AUCB9N7ELUIyFYBgRYUZPEcOKTT4ZSUUdFLvEmCZc=; b=C/LkAhBUzp2VLqKP2Nfz9a9BB1vsIx42ManKuqx3p6fqGDCxTgRBigmTJWl+G/WLh+ m4ms6//NQVeMLRHyhb68+Cw0b1qHE7X4ISywi8TIFfw31VyG4R006E4jNV3+wp/UrDI/ 8+wmqzreXr7B0kSSMrqFYSLS5nGpLL7wJSFyQPTk0hXPvKT/3nli22RStxs5d0p5vkgt 5YpqHXa0PUoO6f0e6A7Fmp63znavyjvkkG96k8LSaL0TgEdE5fsTTFl2Vq0XUPp43ekE c40fKbwEu57aKBY+DRi25/0faCbWPhyjYvSSBaIACSqGrwc67BqHHZepUqM4cl9DK1fN rfcQ== X-Gm-Message-State: ALoCoQmaai47o1Fp+ylbNRBruDrSkXHA+v9FhIUQlOsOONhPsbSFUwgfe7QpGM3ExgCQwTiFmXso X-Received: by 10.194.223.9 with SMTP id qq9mr18057208wjc.36.1416235846011; Mon, 17 Nov 2014 06:50:46 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id p7sm34164203wjo.38.2014.11.17.06.50.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 06:50:45 -0800 (PST) Message-ID: <546A0B48.7020300@multiplay.co.uk> Date: Mon, 17 Nov 2014 14:50:48 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> In-Reply-To: <20141117143323.GH44537@home.opsec.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 14:50:49 -0000 On 17/11/2014 14:33, Kurt Jaeger wrote: > Hi! > >> If your running a custom kernel do you have both the options for aac enable: > It's the GENERIC kernel. > Does a kernel with options AACRAID_DEBUG shed any light? From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 14:52:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40B9599D for ; Mon, 17 Nov 2014 14:52:05 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE1D8F5B for ; Mon, 17 Nov 2014 14:52:04 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XqNeu-000G5R-IE for freebsd-stable@freebsd.org; Mon, 17 Nov 2014 15:52:04 +0100 Date: Mon, 17 Nov 2014 15:52:04 +0100 From: Kurt Jaeger To: FreeBSD Stable Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <20141117145204.GI44537@home.opsec.eu> References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 14:52:05 -0000 Hi! > >> If your running a custom kernel do you have both the options for aac enable: > > It's the GENERIC kernel. > That's curious. In order to have direct access to the disks I > had to patch aac_cam.c. Maybe you were > using a patched file and you forgot? I upgraded using freebsd-update and upgraded GENERIC. What additional patch would be needed ? -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 15:04:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5815ECE for ; Mon, 17 Nov 2014 15:04:20 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F14CE7 for ; Mon, 17 Nov 2014 15:04:20 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XqNqk-000G6d-08; Mon, 17 Nov 2014 16:04:18 +0100 Date: Mon, 17 Nov 2014 16:04:17 +0100 From: Kurt Jaeger To: Steven Hartland , FreeBSD Stable Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <20141117150417.GJ44537@home.opsec.eu> References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <546A0B48.7020300@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A0B48.7020300@multiplay.co.uk> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 15:04:20 -0000 Hi! > >> If your running a custom kernel do you have both the options for aac enable: > > It's the GENERIC kernel. > > > Does a kernel with options AACRAID_DEBUG shed any light? I can try to reproduce it -- but not on the same system, as that is a production system. It will take a while. I'm asking if other have seen similar issues. -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 15:26:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D4A0D70 for ; Mon, 17 Nov 2014 15:26:02 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 292ED37F for ; Mon, 17 Nov 2014 15:26:01 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id B346E9DD418; Mon, 17 Nov 2014 16:25:52 +0100 (CET) Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20141117145204.GI44537@home.opsec.eu> Date: Mon, 17 Nov 2014 16:25:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> <20141117145204.GI44537@home.opsec.eu> To: Kurt Jaeger X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 15:26:02 -0000 On Nov 17, 2014, at 3:52 PM, Kurt Jaeger wrote: > Hi! >=20 >>>> If your running a custom kernel do you have both the options for = aac enable: >=20 >>> It's the GENERIC kernel. >=20 >> That's curious. In order to have direct access to the disks I >> had to patch aac_cam.c. Maybe you were >> using a patched file and you forgot? >=20 > I upgraded using freebsd-update and upgraded GENERIC. What additional=20= > patch would be needed ? Beware, it's just my case, not necessarily others'.=20 My controller (built-in in a SunFire X4240) I needed to comment out = several lines so that the passthrough driver attaches the disks to the "da" driver. It = was suggested=20 back in 2007 (with flashing warnings all over the place!) by Scott Long = answering my question about ZFS and avoiding "intelligent RAID controller" = features entirely. These are the two relevant threads: http://lists.freebsd.org/pipermail/freebsd-scsi/2007-October/003223.html = http://lists.freebsd.org/pipermail/freebsd-scsi/2007-November/003234.html They are related to the "mfi" cards, but I posted them so that you = have some historical context. Of course now we know that it's far better to repurpose them by flashing = with IT-mode firmware (turning them into "HBA, period" devices). Back to our "aac". I have that SunFire machine in which I was unable to = access the disks individually. So I checked the source code for aac_cam.c and I = found out that the same trick works. This is what I do. Beware! This is working for me since 2012, but of = course there's no guarantee. At some point (with some 9. x version) the kludge stopped identifyng SSD = disks connected to the backplane, but it works with the SAS disks I am using. Again, USE WITH CAUTION! Something like this should be made more or less = "official". --- aac_cam.c 2014-11-17 15:20:24.011457711 +0000 +++ aac_cam.c.orig 2014-11-17 15:08:13.116702602 +0000 @@ -129,7 +129,7 @@ return; } =20 - if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, + if (xpt_create_path(&ccb->ccb_h.path, NULL, cam_sim_path(camsc->sim), target_id, CAM_LUN_WILDCARD) !=3D CAM_REQ_CMP) { xpt_free_ccb(ccb); @@ -548,9 +548,8 @@ /* * We want DASD and PROC devices to only be * visible through the pass device. - * CHANGE: WE WANT DASD DEVICES VISIBLE! */ - if ((/* IGNORE THIS: (device =3D=3D T_DIRECT) || */ + if (((device =3D=3D T_DIRECT) || (device =3D=3D T_PROCESSOR) || (sc->flags & AAC_FLAGS_CAM_PASSONLY))) { /* Borja. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 16:39:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AB5B5A7 for ; Mon, 17 Nov 2014 16:39:40 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8AC112D for ; Mon, 17 Nov 2014 16:39:39 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id l18so1704098wgh.40 for ; Mon, 17 Nov 2014 08:39:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IAJ20KchiwQr2OAeRCKivR5clqTVm4O92dURkbnpEy4=; b=RgpHpsU3DdJGWIi5gbrnT5Mdw20TZo0Xzbq4NiRCqS4K8goKJDwFdxznlJpdjMSEvR 0rtsvVd5E9KGQ+04hKWaGpB2YvhFhO/CfQQtnHhIzG9jWFzAmVRwmgyBb3QHX8KPJnRI jVSr2asN2ld2sVDwiv2r8rhQSHcnVjnjNs73A5kD4NNhbAYFTHMSXQCZWxKmUBtq+reH AtUU5T9uXalgwxUlw+/u3G3La7TsOmbJZayyvE7zrT3eYRUlrjaDg8sxgaQ7dVW01Lbk 1QXDcnZFXmRp6MOVd4sHIPBXTH3wesjJY3WVrle4FEpUpFxrgfQlbm1YOe5rdv5SBSXW w/Lw== X-Gm-Message-State: ALoCoQm5rIyy6p7dzGZ6X7d+vhe1EMS1qwWoNZNTqjCAdHx00yuODpQedSLbY3v00MDafW7sffkD X-Received: by 10.194.5.227 with SMTP id v3mr41155954wjv.63.1416242378134; Mon, 17 Nov 2014 08:39:38 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id dc8sm15947513wib.7.2014.11.17.08.39.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 08:39:37 -0800 (PST) Message-ID: <546A24CD.6040600@multiplay.co.uk> Date: Mon, 17 Nov 2014 16:39:41 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> <20141117145204.GI44537@home.opsec.eu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 16:39:40 -0000 On 17/11/2014 15:25, Borja Marcos wrote: > On Nov 17, 2014, at 3:52 PM, Kurt Jaeger wrote: > >> Hi! >> >>>>> If your running a custom kernel do you have both the options for aac enable: >>>> It's the GENERIC kernel. >>> That's curious. In order to have direct access to the disks I >>> had to patch aac_cam.c. Maybe you were >>> using a patched file and you forgot? >> I upgraded using freebsd-update and upgraded GENERIC. What additional >> patch would be needed ? > Beware, it's just my case, not necessarily others'. > > My controller (built-in in a SunFire X4240) I needed to comment out several lines > so that the passthrough driver attaches the disks to the "da" driver. It was suggested > back in 2007 (with flashing warnings all over the place!) by Scott Long answering > my question about ZFS and avoiding "intelligent RAID controller" features entirely. > > These are the two relevant threads: > http://lists.freebsd.org/pipermail/freebsd-scsi/2007-October/003223.html > http://lists.freebsd.org/pipermail/freebsd-scsi/2007-November/003234.html > > They are related to the "mfi" cards, but I posted them so that you have some historical context. > Of course now we know that it's far better to repurpose them by flashing with IT-mode firmware > (turning them into "HBA, period" devices). > > Back to our "aac". I have that SunFire machine in which I was unable to access > the disks individually. So I checked the source code for aac_cam.c and I found > out that the same trick works. > > This is what I do. Beware! This is working for me since 2012, but of course there's no guarantee. > At some point (with some 9. x version) the kludge stopped identifyng SSD disks connected to the > backplane, but it works with the SAS disks I am using. > > Again, USE WITH CAUTION! Something like this should be made more or less "official". > > > > --- aac_cam.c 2014-11-17 15:20:24.011457711 +0000 > +++ aac_cam.c.orig 2014-11-17 15:08:13.116702602 +0000 > @@ -129,7 +129,7 @@ > return; > } > > - if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, > + if (xpt_create_path(&ccb->ccb_h.path, NULL, > cam_sim_path(camsc->sim), > target_id, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { > xpt_free_ccb(ccb); > @@ -548,9 +548,8 @@ > /* > * We want DASD and PROC devices to only be > * visible through the pass device. > - * CHANGE: WE WANT DASD DEVICES VISIBLE! > */ > - if ((/* IGNORE THIS: (device == T_DIRECT) || */ > + if (((device == T_DIRECT) || > (device == T_PROCESSOR) || > (sc->flags & AAC_FLAGS_CAM_PASSONLY))) { > /* As you say that looks very hack. I'm wondering if the following commit was the cause: https://svnweb.freebsd.org/base?view=revision&revision=257847 Specifically: https://svnweb.freebsd.org/base/head/sys/dev/aacraid/aacraid_cam.c?annotate=257847&pathrev=257847#l1231 Could you try backing that out and see if it fixes it for you? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 17:08:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A2DE101 for ; Mon, 17 Nov 2014 17:08:17 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52C00750 for ; Mon, 17 Nov 2014 17:08:17 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAHH90Uq007079 for ; Mon, 17 Nov 2014 09:09:01 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "freebsd-stable@freebsd.org" In-Reply-To: References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> , From: "Chris H" Subject: Re: best overall upgrade from 8.x? Date: Mon, 17 Nov 2014 09:09:01 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <971085e211564c84a0460ca945eda837@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 17:08:17 -0000 On Sat, 15 Nov 2014 09:26:22 -0600 Adam Vande More wrote > On Sat, Nov 15, 2014 at 9:20 AM, Dimitry Andric wrote: > > > On 15 Nov 2014, at 13:53, Adrian Wontroba wrote: > > > > > > On Sat, Nov 15, 2014 at 12:44:33PM +0100, Andrea Venturoli wrote: > > >> On 11/15/14 05:48, Kevin Oberman wrote: > > >>> I'd wait a month or so and, if no problems that might impact you pop > > up, > > >>> I'd go with 10.1 > > >> Uh... is direct upgrade (using sources) possible from 8.4 to 10.1? > > >> No need to step through 9.x? > > > > > > Even the move from 9.2 (a near year old 9/stable) to 10.1 (stable/10 as > > > of about 3 weeks ago) is slightly problematic. > > > > > > Following the normal upgrade procedure of installkernel and then > > > rebooting with the userland untouched runs into a problem whereby > > > rc.conf falls apart with a shower of eval errors, no networking, ... > > > > > > I do not know the cause. > > > > I almost certainly know the cause: you are supposed to reboot into > > single user mode after installkernel. > > > This is almost certainly not the cause. Something else in the horked up > given procedure or some omission of facts is the likely cause. Fortunately, > nice people have already created documentation on how to do this: > > https://www.freebsd.org/doc/handbook/makeworld.html FWIW The following has worked perfectly for ~10yrs. NOTE personal experience indicates that regression issues introduced by pkg(8), makes >=8.3-* the minimum starting point. YMMV I have used the following for ~10yrs. w/o issue (comments added for *hopeful* clarity). The IMMEDIATELY following, is only relevant RE-building world/kernel: cd /usr/obj chflags -R noschg * rm -rf * cd /usr/src make buildworld NOTES: SINGLE CPU: make -j4 buildworld NOTE: MULTI CPU: make -j(6 through ??) buildworld # pre version 9 make kernel-toolchain make -DALWAYS_CHECK_MAKE buildkernel KERNCONF= make -DALWAYS_CHECK_MAKE installkernel KERNCONF= reboot (in single user mode) fsck -p (optional, but a good idea) mount -u / mount -a -t ufs swapon -a (most cases; optional) adjkerntz -i (not always necessary, but DO check current time/date, just in case) mergemaster -p cp -Rp /etc /etc.old cd /usr/src make installworld mergemaster -F or mergemaster -vF (my personal choice) or mergemaster -cvF make delete-old reboot HTH --Chris > > > -- > Adam > _______________________________________________ > 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 Mon Nov 17 19:40:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7417AECD for ; Mon, 17 Nov 2014 19:40:50 +0000 (UTC) Received: from email.sasag.ch (email.sasag.ch [87.245.64.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "email.sasag.ch", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 037D8AA2 for ; Mon, 17 Nov 2014 19:40:49 +0000 (UTC) Received: from VS-W08-KEWV-EXC.sasag.intra ([fe80::605b:6dc2:7cbf:7fb6]) by VS-W08-KEWV-EXC.sasag.intra ([fe80::605b:6dc2:7cbf:7fb6%11]) with mapi id 14.02.0387.000; Mon, 17 Nov 2014 20:39:34 +0100 From: Michael Richter To: "freebsd-stable@freebsd.org" Subject: RE: aacraid drives missing after update 10.0 -> 10.1 ? Thread-Topic: aacraid drives missing after update 10.0 -> 10.1 ? Thread-Index: AdACnjYeLst3+PVjRIeh4j5IoTcmeg== Date: Mon, 17 Nov 2014 19:39:32 +0000 Message-ID: <6A1B0F2AE603944A84F7F99010C303698691138F@VS-W08-KEWV-EXC.sasag.intra> Accept-Language: de-CH, en-US Content-Language: de-CH X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.26] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 19:40:50 -0000 I had the same issue after the upgrade. @Steve Thanks I have changed the aacraid_cam.c and then it was working again Freundliche Gr=FCsse sasag Kabelkommunikation AG Michael Richter Professional Bachelor ODEC in Engineering mrichter@sasag.ch 052 633 01 71 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 19:59:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27D9A462 for ; Mon, 17 Nov 2014 19:59:48 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D25F6CB2 for ; Mon, 17 Nov 2014 19:59:47 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XqSSg-000GmP-Vt; Mon, 17 Nov 2014 20:59:46 +0100 Date: Mon, 17 Nov 2014 20:59:46 +0100 From: Kurt Jaeger To: Steven Hartland Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <20141117195946.GM44537@home.opsec.eu> References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> <20141117145204.GI44537@home.opsec.eu> <546A24CD.6040600@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A24CD.6040600@multiplay.co.uk> Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 19:59:48 -0000 Hi! > >>>> It's the GENERIC kernel. > >>> That's curious. In order to have direct access to the disks I > >>> had to patch aac_cam.c. Maybe you were > >>> using a patched file and you forgot? > >> I upgraded using freebsd-update and upgraded GENERIC. What additional > >> patch would be needed ? > > Beware, it's just my case, not necessarily others'. [...] > As you say that looks very hack. I'm wondering if the following commit > was the cause: > https://svnweb.freebsd.org/base?view=revision&revision=257847 > > Specifically: > https://svnweb.freebsd.org/base/head/sys/dev/aacraid/aacraid_cam.c?annotate=257847&pathrev=257847#l1231 > > Could you try backing that out and see if it fixes it for you? I've opened PR 195119 to track this. -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 20:05:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCB967CB for ; Mon, 17 Nov 2014 20:05:53 +0000 (UTC) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51C90DB7 for ; Mon, 17 Nov 2014 20:05:52 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so25855590wgg.32 for ; Mon, 17 Nov 2014 12:05:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TJZxym9yRIkGMwjx1G7/ttTAuoUKhv7Gzo8e05P0UxA=; b=BNT6lPi2nz/vSI59guEw3jTRt14VZTl9//2cIr5bBMO7cNlEpkhDaus/FqVF59fOk6 XF/EAtL3bw5WmRoGytIlHRark7q0J+hQ+fJKePXNcOXqEqkm7Gqou1auxny6iJqCmlGe Tf+KB7WsbPRHwpW0LHlvZfBj9EUfbnMS2DJi4hkXr3jqSUlP9kORjrgvp/Ga0S+EBNjh 0HxhmSmVsdsZMUmY2Al19OGMex7ben8BHivlAEXhlJgg9SJQ1XU7350W5eQlFJW6kgeU qk2atmJ98d5zYikVOzkMmRvanHIV997qEaQK1urTC6PJ0VCBC0dnb8HfZ/Ent/47KPnL MmCQ== X-Gm-Message-State: ALoCoQlZIpMFhvxfKvBDxSNqFei7rPrg/YnwEJrJd8zINGSHNd7Euo6GqvVrZCTIaDrU5nyT0A5j X-Received: by 10.180.109.194 with SMTP id hu2mr33749776wib.24.1416254750628; Mon, 17 Nov 2014 12:05:50 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id n4sm16598716wiz.17.2014.11.17.12.05.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 12:05:49 -0800 (PST) Message-ID: <546A5521.7080302@multiplay.co.uk> Date: Mon, 17 Nov 2014 20:05:53 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richter , "freebsd-stable@freebsd.org" , achim@freebsd.org Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? References: <6A1B0F2AE603944A84F7F99010C303698691138F@VS-W08-KEWV-EXC.sasag.intra> In-Reply-To: <6A1B0F2AE603944A84F7F99010C303698691138F@VS-W08-KEWV-EXC.sasag.intra> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 17 Nov 2014 20:05:53 -0000 On 17/11/2014 19:39, Michael Richter wrote: > I had the same issue after the upgrade. > > @Steve > Thanks I have changed the aacraid_cam.c and then it was working again > So I'm guessing that for some reason sc->hint_flags doesn't include bit 4 for your controller. Could you add the following where that code was removed from so we can see what your device has: device_printf(sc->aac_dev, "hint_flags: 0x%08x, data_ptr[0]: 0x%02x\n", sc->hint_flags, ccb->csio.data_ptr[0]); @achim: Are there any other details which would aid in debugging this? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 05:15:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECC21170 for ; Tue, 18 Nov 2014 05:15:36 +0000 (UTC) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 82CFAD7A for ; Tue, 18 Nov 2014 05:15:34 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 1FD8D21D44 for ; Tue, 18 Nov 2014 05:15:28 +0000 (GMT) Received: from modem-209-101-60-62.vip.uk.com (HELO swelter.hanley.stade.co.uk) (62.60.101.209) (smtp-auth username postmaster%pop3.stade.co.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Tue, 18 Nov 2014 05:15:27 +0000 Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.9/8.14.9) with ESMTP id sAI5FDkr021334 for ; Tue, 18 Nov 2014 05:15:13 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.9/8.14.9/Submit) id sAI5FCR9021333 for freebsd-stable@freebsd.org; Tue, 18 Nov 2014 05:15:12 GMT (envelope-from aw1) Date: Tue, 18 Nov 2014 05:15:12 +0000 From: Adrian Wontroba To: freebsd-stable@freebsd.org Subject: Re: best overall upgrade from 8.x? Message-ID: <20141118051512.GB1995@swelter.hanley.stade.co.uk> Reply-To: aw1@stade.co.uk References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> <1416068269.4781.144.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416068269.4781.144.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 10.1-STABLE Organization: Oh dear, I've joined one again. User-Agent: Mutt/1.5.22 (2013-10-16) X-Gradwell-MongoId: 546ad5ef.140b8-481f-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.stade.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 05:15:37 -0000 On Sat, Nov 15, 2014 at 09:17:49AM -0700, Ian Lepore wrote: > On Sat, 2014-11-15 at 09:26 -0600, Adam Vande More wrote: > > On Sat, Nov 15, 2014 at 9:20 AM, Dimitry Andric wrote: > > > > > On 15 Nov 2014, at 13:53, Adrian Wontroba wrote: > > > > > > > > On Sat, Nov 15, 2014 at 12:44:33PM +0100, Andrea Venturoli wrote: > > > >> On 11/15/14 05:48, Kevin Oberman wrote: > > > >>> I'd wait a month or so and, if no problems that might impact you pop > > > up, > > > >>> I'd go with 10.1 > > > >> Uh... is direct upgrade (using sources) possible from 8.4 to 10.1? > > > >> No need to step through 9.x? > > > > > > > > Even the move from 9.2 (a near year old 9/stable) to 10.1 (stable/10 as > > > > of about 3 weeks ago) is slightly problematic. > > > > > > > > Following the normal upgrade procedure of installkernel and then > > > > rebooting with the userland untouched runs into a problem whereby > > > > rc.conf falls apart with a shower of eval errors, no networking, ... > > > > > > > > I do not know the cause. > > > > > > I almost certainly know the cause: you are supposed to reboot into > > > single user mode after installkernel. > > > > > > This is almost certainly not the cause. Something else in the horked up > > given procedure or some omission of facts is the likely cause. Fortunately, > > nice people have already created documentation on how to do this: > > > > https://www.freebsd.org/doc/handbook/makeworld.html > > > > > > No. It is absolutely the cause. It's clear from the original poster's > report of errors in rc scripts after booting on the new kernel. If the > instructions were followed you'd end up in single-user mode and the old > rc scripts would never have been run before the installworld put the new > ones in. Thanks Ian. Now that at $JOB we are no longer using NFS, and all machines have /usr/src and /usr/obj populated (transferred from the build machine), rebooting into single user mode after installing the new kernel becomes much easier. I'll try this on further test 9.2-STABLE to 10.1-STABLE rollouts. -- Adrian Wontroba From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 06:13:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3F3D8FA for ; Tue, 18 Nov 2014 06:13:12 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A7A9388 for ; Tue, 18 Nov 2014 06:13:12 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so3928283ieb.40 for ; Mon, 17 Nov 2014 22:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l3lVGkkIqbckXwnvb6IeSUJlePjgLb/qoI5cyL5V/yE=; b=kagtYU6tJO27xGo3Seq8L5XJ1vIrfLyzRrkp2M5P/HuwCyMoohiktfu+QrQj1TYxn2 txteZbrk1K1bh/WpMj5r2+kYNA9nsRKt9PIfIn39cq8RLlTQ9M0lbuYrdZ0kPYX6/ZGQ xIm9eszRqUOg3drF7PJCwxSN5Oum+Uo1WNvIRMYHBkh/yieie41KklPRAzfInxLf1Kiy yegvOJEPV16uNGb/g7mulN3N0Wyu5XUJkVLcZIGgxQfbTeCVQnV4kT+pRfDNNwN4lQ1m uUG3ruq4pVz0QNv6d6KVbBaE0Sd3KYXjM1DIoWOP0CGOn+voo61BgnTFiVaI3XlrLG4f OQNQ== MIME-Version: 1.0 X-Received: by 10.50.79.166 with SMTP id k6mr976096igx.0.1416291191914; Mon, 17 Nov 2014 22:13:11 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.7.169 with HTTP; Mon, 17 Nov 2014 22:13:11 -0800 (PST) In-Reply-To: <971085e211564c84a0460ca945eda837@ultimatedns.net> References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> <971085e211564c84a0460ca945eda837@ultimatedns.net> Date: Mon, 17 Nov 2014 22:13:11 -0800 X-Google-Sender-Auth: la9H7minqlqfIHNvPEEG5Kzr8mg Message-ID: Subject: Re: best overall upgrade from 8.x? From: Kevin Oberman To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 06:13:12 -0000 This is a bit nit-picky, but... (in-line) NOTE personal experience indicates that regression issues introduced > by pkg(8), makes >=8.3-* the minimum starting point. YMMV > > I have used the following for ~10yrs. w/o issue (comments added for > *hopeful* clarity). > > The IMMEDIATELY following, is only relevant RE-building world/kernel: > cd /usr/obj > chflags -R noschg * > rm -rf * > > > cd /usr/src > make buildworld > > NOTES: > SINGLE CPU: make -j4 buildworld > > NOTE: > MULTI CPU: make -j(6 through ??) buildworld > > # pre version 9 > make kernel-toolchain > > make -DALWAYS_CHECK_MAKE buildkernel KERNCONF= > I would add -jN to this using the same value for 'N' as used for buildworld make -DALWAYS_CHECK_MAKE installkernel KERNCONF= > > reboot (in single user mode) > > fsck -p (optional, but a good idea) > mount -u / > Redundant before the fact as the next command (mount -a -t ufs) does this, too mount -a -t ufs > swapon -a (most cases; optional) > > adjkerntz -i (not always necessary, but DO check current time/date, just in > case) > In more fetail, if the hardware clock is UTC, this is not required. If /etc/wall_cmos_clock exists, this is needed, but you really should do it BEFORE mounting disks. UPDATING shows it right after the fsck. It avoids any possibility of something being time-stamped in the future. > > mergemaster -p > This is way, way to late. On at least one case, this would have lead to a very awkward failure of installworld. The man page is explicit that it should be run before buildworld. This is the only thing in this that is really, really wrong and can lead to a recoverable, but very annoying failure. > > cp -Rp /etc /etc.old > Not really needed, but good for the "belt and braces" type. > > cd /usr/src > > make installworld > > mergemaster -F > or mergemaster -vF (my personal choice) > or mergemaster -cvF > > make delete-old > This can be a bit painful as you are prompted for every file. I suggest "make check-old" and then "rm -rf" any directories listed as ready for deletion. direcctories are listed near the end, just before libs. > > reboot > > HTH > > --Chris > -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 06:49:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E90CDF5C for ; Tue, 18 Nov 2014 06:49:32 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B32748A1 for ; Tue, 18 Nov 2014 06:49:32 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAI6oIL6005350; Mon, 17 Nov 2014 22:50:18 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Kevin Oberman In-Reply-To: References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> <971085e211564c84a0460ca945eda837@ultimatedns.net>, From: "Chris H" Subject: Re: best overall upgrade from 8.x? Date: Mon, 17 Nov 2014 22:50:18 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <3930066eddaa3b17754f5f9cdfba5e6d@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 06:49:33 -0000 On Mon, 17 Nov 2014 22:13:11 -0800 Kevin Oberman wrote > This is a bit nit-picky, but... (in-line) > > NOTE personal experience indicates that regression issues introduced > > by pkg(8), makes >=8.3-* the minimum starting point. YMMV > > > > I have used the following for ~10yrs. w/o issue (comments added for > > *hopeful* clarity). > > > > The IMMEDIATELY following, is only relevant RE-building world/kernel: > > cd /usr/obj > > chflags -R noschg * > > rm -rf * > > > > > > cd /usr/src > > make buildworld > > > > NOTES: > > SINGLE CPU: make -j4 buildworld > > > > NOTE: > > MULTI CPU: make -j(6 through ??) buildworld > > > > # pre version 9 > > make kernel-toolchain > > > > make -DALWAYS_CHECK_MAKE buildkernel KERNCONF= > > > I would add -jN to this using the same value for 'N' as used for buildworld > > make -DALWAYS_CHECK_MAKE installkernel KERNCONF= > > > > reboot (in single user mode) > > > > fsck -p (optional, but a good idea) > > mount -u / > > > Redundant before the fact as the next command (mount -a -t ufs) does this, > too > > mount -a -t ufs > > swapon -a (most cases; optional) > > > > adjkerntz -i (not always necessary, but DO check current time/date, just in > > case) > > > In more fetail, if the hardware clock is UTC, this is not required. If > /etc/wall_cmos_clock exists, this is needed, but you really should do it > BEFORE mounting disks. UPDATING shows it right after the fsck. It avoids > any possibility of something being time-stamped in the future. > > > > > mergemaster -p > > > This is way, way to late. On at least one case, this would have lead to a > very awkward failure of installworld. The man page is explicit that it > should be run before buildworld. This is the only thing in this that is > really, really wrong and can lead to a recoverable, but very annoying > failure. 10yrs. and a few thousand installs, says otherwise... BUT, the more I know, the more I know I don't know. :) > > > > > > cp -Rp /etc /etc.old > > > Not really needed, but good for the "belt and braces" type. Yes. Just like recent dump(8)'s. ;) > > > > > cd /usr/src > > > > make installworld > > > > mergemaster -F > > or mergemaster -vF (my personal choice) > > or mergemaster -cvF > > > > make delete-old > > > This can be a bit painful as you are prompted for every file. I suggest > "make check-old" and then "rm -rf" any directories listed as ready for > deletion. direcctories are listed near the end, just before libs. > > > > > reboot > > > > HTH > > > > --Chris > > > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com --Chris From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 06:55:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2BB2111 for ; Tue, 18 Nov 2014 06:55:36 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41422956 for ; Tue, 18 Nov 2014 06:55:36 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id n15so17510876lbi.34 for ; Mon, 17 Nov 2014 22:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hTluUeSEp7Mfl9jd0pS3MxdnM6pdl5XT4c5AwgwzsKs=; b=sWt8Z1jUA/I2tFLEJgw3E1jXjmvaZ2KqGci9OonQAULNEVdZw9oyIC9ZCFLa2+3lIx Eu+3YOrJ5v+nFRJEMzNRDWYuI+NlP0NG3e1gpnMPf0rhnwbb3XDT63oaQzI+oybIOnMB 11WngKJAzIyQBy9yovYo0HxlmA0AOlzGwHElbJ4O7B2+1IKe5dWB20Yitci+7/wWBwNl kfxJXoWm0pHV2ptz2V6T8lV8iR6l+YeC5cQQ+6azX4yc5jXcM1iGPhp1qUoVochTsk0i mREiqjrswDBPFvJGZMMB0/a6XV5geU73NceTFTsAKiWYVvDJWkhuiAgToGGyTnBIidxn emLQ== MIME-Version: 1.0 X-Received: by 10.152.207.71 with SMTP id lu7mr16223138lac.81.1416293734279; Mon, 17 Nov 2014 22:55:34 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Mon, 17 Nov 2014 22:55:34 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Nov 2014 22:55:34 -0800 X-Google-Sender-Auth: QA2ihnpa-HBjnE510Q_dQHb8iqo Message-ID: Subject: Re: best overall upgrade from 8.x? From: Craig Rodrigues To: Royce Williams Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 06:55:36 -0000 On Fri, Nov 14, 2014 at 7:44 PM, Royce Williams wrote: > I have some 8.x boxes that I'm looking to start planning to transition > before 8.4 is likely to go EOL next year. > > All other things being equal, what's the general consensus on where to > upgrade to from 8.x ... 9.x, or 10.x? > Do you have one of your machines available for experimentation to do a test upgrade from 8.x to 10.1-RELEASE via freebsd-update, and also pkg_add to pkgng? I would be curious what your experience with this would be, so that we can fix documentation for doing such an upgrade. -- Craig From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 07:31:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FA4087E for ; Tue, 18 Nov 2014 07:31:50 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDA55C03 for ; Tue, 18 Nov 2014 07:31:48 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPSA id 52FCC9DD3E7; Tue, 18 Nov 2014 08:31:45 +0100 (CET) Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <546A24CD.6040600@multiplay.co.uk> Date: Tue, 18 Nov 2014 08:31:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> <20141117145204.GI44537@home.opsec.eu> <546A24CD.6040600@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 07:31:50 -0000 On Nov 17, 2014, at 5:39 PM, Steven Hartland wrote: > As you say that looks very hack. I'm wondering if the following commit = was the cause: > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D257847 >=20 > Specifically: > = https://svnweb.freebsd.org/base/head/sys/dev/aacraid/aacraid_cam.c?annotat= e=3D257847&pathrev=3D257847#l1231 >=20 > Could you try backing that out and see if it fixes it for you? Now that I notice, my card is not handled by "aacraid", but "aac" = although fortunately the driver structure is pretty similar. In my case, "aac" did never expose the drives, part of a logical volume = or not.=20 Borja. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 09:03:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E382979B for ; Tue, 18 Nov 2014 09:03:28 +0000 (UTC) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.70]) by mx1.freebsd.org (Postfix) with ESMTP id 99D21752 for ; Tue, 18 Nov 2014 09:03:28 +0000 (UTC) Received: from nm43.abv.bg (nm43.ni.bg [192.168.151.18]) by smtp-out.abv.bg (Postfix) with ESMTP id D39C450DDE0 for ; Tue, 18 Nov 2014 11:03:20 +0200 (EET) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=FGmmar5a4jKKU2wt9TucdDIcNIhXQdeS4UTSPOpUJFCywXYfNr3gG0eTxlNBDxdOu D3k+7ZwHgwkS2faUuCcKz7bvCpzwdZNInphcWSrC0dxEqo99F4glTDptsHc54zyT4qq bGqhw9xOq3COuFw6G3gVxXiTm71UJnmqEKHJABg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1416301400; bh=N89EP5ftlqfke9iivdjS142/LdL3HLtW7jVOo+97D+w=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=m23EebHKgEAgly3jBW6AZdvYrkfuNpg8 Yf5IZog7iPpPuOqf2Kri+bs9tCW2+gn8ng5/rcNdjhZkRNqLF2TmnDhT9GT6T6xSlzh u00yL2m1KaPtCriKnoPVFwHbJMWOPiqFBL6BpFpgGSfs4NzEZi1lvFXsa5zRDkM5PbW QBQ20= Received: from nm43.abv.bg (localhost.localdomain [127.0.0.1]) by nm43.abv.bg (Postfix) with ESMTP id ED328239D4C for ; Tue, 18 Nov 2014 11:03:20 +0200 (EET) Date: Tue, 18 Nov 2014 11:03:20 +0200 (EET) From: Quick Fox To: freebsd-stable@freebsd.org Message-ID: <416926212.66988.1416301400966.JavaMail.apache@nm43.abv.bg> Subject: freebsd-update upgrade progress MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: AbvMail 2.0 X-Originating-IP: 82.119.86.218 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 09:03:29 -0000 Hi, I was doing "freebsd-update upgrade -r 10.1-RELEASE" and while waiting for "Fetching files" to complete, which took some time, was thinking - is it possible to show progress like "Fetching patches"? I have a feeling there is a reason to be like that, but I also think it would be helpful to have an indication of the progress, if possible. Bye, Quick Fox From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 09:40:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE059EAA for ; Tue, 18 Nov 2014 09:40:28 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BE3FA6D for ; Tue, 18 Nov 2014 09:40:27 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id l18so3476447wgh.40 for ; Tue, 18 Nov 2014 01:40:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Y3s9qggt/dnhg5a1UHkTg3On1jBQzjuUq2OjBVnKM9s=; b=jSdda8QXGjj8EkArsr2ElLX8aMwuKgp/EtEbYKQ5MkvJEQBz/TTXhWi8pln8G4vIXL RfkaygGJw1y+nFipNYFOiqAu+HpDOjlRonMEJ9IVyL/clF6rMlxEnDsq1+wZ5ohjmM0J GZSdZLNj0FD2dvUDY+FbwWNG1idY2xU4DdBkb9wG8vibWQ9552whgYxGPPN+gxJLQSBH zlAVNj+kRm7cGfTR/CLU0FLWrKLiKIAUidKNvYUZfXY8iIggNQNHrFVkzazsym0wDfXO uetMBLA7rtfeF08xIe8PZupxwM/uipNVd5lh5xbHsCqsvc0pH9okrBiHWgQl/XDeKBFE nCIA== X-Gm-Message-State: ALoCoQmuJG62rZUTemYaEDnZj2p1zUdCjkTFzPXIDTNHyZpfOOqMKnrq0EP7hZB22EwFChIibHn4 X-Received: by 10.180.8.34 with SMTP id o2mr37259483wia.23.1416303625243; Tue, 18 Nov 2014 01:40:25 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ge17sm18799657wic.0.2014.11.18.01.40.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Nov 2014 01:40:24 -0800 (PST) Message-ID: <546B140D.5010103@multiplay.co.uk> Date: Tue, 18 Nov 2014 09:40:29 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richter , "freebsd-stable@freebsd.org" , achim@freebsd.org Subject: Re: AW: aacraid drives missing after update 10.0 -> 10.1 ? References: <6A1B0F2AE603944A84F7F99010C303698691138F@VS-W08-KEWV-EXC.sasag.intra>, <546A5521.7080302@multiplay.co.uk> <6A1B0F2AE603944A84F7F99010C3036986911416@VS-W08-KEWV-EXC.sasag.intra> In-Reply-To: <6A1B0F2AE603944A84F7F99010C3036986911416@VS-W08-KEWV-EXC.sasag.intra> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 09:40:28 -0000 So as I suspected the drivers are flagged as a log device but the controller doesn't have bit 4 set on its hint_flags. Out of interest does the controller have a bios / firmware level option to expose the disks as JBOD or similar? @achim do you have any tech specs with regards these bits? Regards Steve On 17/11/2014 22:40, Michael Richter wrote: > Here the output from dmesg: > > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > aacraid0: hint_flags: 0x00000000, data_ptr[0]: 0x20 > > > > ________________________________________ > Von: Steven Hartland [killing@multiplay.co.uk] > Gesendet: Montag, 17. November 2014 21:05 > An: Michael Richter; freebsd-stable@freebsd.org; achim@freebsd.org > Betreff: Re: aacraid drives missing after update 10.0 -> 10.1 ? > > On 17/11/2014 19:39, Michael Richter wrote: >> I had the same issue after the upgrade. >> >> @Steve >> Thanks I have changed the aacraid_cam.c and then it was working again >> > So I'm guessing that for some reason sc->hint_flags doesn't include bit > 4 for your controller. > > Could you add the following where that code was removed from so we can > see what your device has: > device_printf(sc->aac_dev, "hint_flags: 0x%08x, data_ptr[0]: 0x%02x\n", > sc->hint_flags, ccb->csio.data_ptr[0]); > > @achim: Are there any other details which would aid in debugging this? > > Regards > Steve From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 09:52:55 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D981B2B8 for ; Tue, 18 Nov 2014 09:52:55 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [176.57.193.164]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.ismobile.com", Issuer "GlobalSign Domain Validation CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B590C12 for ; Tue, 18 Nov 2014 09:52:55 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id C22892B54A1 for ; Tue, 18 Nov 2014 09:52:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=selector1; bh=iJFlSFQI7rBZgEZwCutM yMVTyrU=; b=nxFMLlQ1zjuiS29NMO8AERXxIta0GsNcYipn0DcFVBUm4LVCkf5k d6jnHRaeFMX+XxvL5HV1bmk+8Ydarzz5849RlynCBoaGAVqVzKRuL3+MRsLmmaEc +CHJljQIg9cSOvJ7TyJcKCD1AGoRVhbLAkrkyKc3SVMqjW+6u1x868o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=selector1; b=DCj/oCnyK2QGlr QsWTV5EV6Q/KO4svPyy0ZnHpEUeXfO39JpE1r7bxcIFHLIX/CHeIQZue5HUod3Ch hfYJFJF8a7xyuVimnkvGewOl/nZeFmKyYFlePLVLYZtDsyqDdGrmLBR4h2TulQUn Aehgt/G40AVTXwKgN1a4wr3D7IehI= Received: from [172.16.2.28] (glz-macbookpro.hq.ismobile.com [172.16.2.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 906012B54A0 for ; Tue, 18 Nov 2014 09:52:50 +0000 (UTC) Date: Tue, 18 Nov 2014 10:52:50 +0100 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: freebsd-stable@freebsd.org Subject: Problem with IPSec tunnel and normal routing Message-ID: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1716 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 09:52:55 -0000 We have a problem with a NanoBSD GW/Router that seems to get it's forwarding screwed up by an IPSec tunnel. +----+ +-------+ | | +----+ | | +-- A 2 -+ | | | | | | 3 -+ GW +-- DMZ --+ FW +--- Internet ---???? ---+ IPSec +----+-- B 4 -+ | | | | endp | | | | +----+ | | +-- C +----+ +-------+ Net 2 - em2 - 192.168.2.0/24 - servers, server-net switches. Net 3 - em1 - 192.168.3.0/24 - workstations, ws-net switches Net 4 - em0 - 192.168.4.0/24 - WiFi access points + VLAN switch DMZ - em5 - XXX.XXX.XXX.128/27 - DMZ and transfer net to outside. IPSec endp - YYY.YYY.YYY.2 Net A - 192.168.45.129/32 Net B - 192.168.45.130/32 Net C - 192.168.40.8/29 Net 2 and Net 3 are setup to allow tunnel to Nets A,B and C. GW is FreeBSD gw01.xxxx.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r274192 IKEv1 etc. is handled by strongswan-5.2.0_1 Left IPSec endpoint is a Clavister VPN GW. After a host on Net 3 has connected through the tunnel to 192.168.45.129 via a NATed VMWare Fusion connection, traffic from that host is received correctly at the GW on Net 3 (em1) but the response from the GW is sent out via the DMZ interface em5. Switching the host to Net 4 i.e. disconnecting the network cable and starting the WiFi restores connectivity. Other hosts on Net 3 that has not communicated via the IPSec tunnel is NOT affected. All routing seems to be correct on the GW so some other mechanism must be at play. Any help appreciated. BR, Goran From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 10:07:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79545690 for ; Tue, 18 Nov 2014 10:07:43 +0000 (UTC) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id F11FBD42 for ; Tue, 18 Nov 2014 10:07:41 +0000 (UTC) Received: from nono (nono.zen.inc [192.168.1.95]) by smtp.zeninc.net (smtpd) with ESMTP id 6780D2798C6 for ; Tue, 18 Nov 2014 11:07:40 +0100 (CET) Received: by nono (Postfix, from userid 1000) id 4AD8220A6C; Tue, 18 Nov 2014 11:07:40 +0100 (CET) Date: Tue, 18 Nov 2014 11:07:40 +0100 From: VANHULLEBUS Yvan To: freebsd-stable@freebsd.org Subject: Re: Problem with IPSec tunnel and normal routing Message-ID: <20141118100739.GB18512@zeninc.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 10:07:43 -0000 Hi. On Tue, Nov 18, 2014 at 10:52:50AM +0100, G?ran L?wkrantz wrote: > We have a problem with a NanoBSD GW/Router that seems to get it's > forwarding screwed up by an IPSec tunnel. > > +----+ +-------+ > | | +----+ | | +-- A > 2 -+ | | | | | | > 3 -+ GW +-- DMZ --+ FW +--- Internet ---???? ---+ IPSec +----+-- B > 4 -+ | | | | endp | | > | | +----+ | | +-- C > +----+ +-------+ > > Net 2 - em2 - 192.168.2.0/24 - servers, server-net switches. > Net 3 - em1 - 192.168.3.0/24 - workstations, ws-net switches > Net 4 - em0 - 192.168.4.0/24 - WiFi access points + VLAN switch > > DMZ - em5 - XXX.XXX.XXX.128/27 - DMZ and transfer net to outside. > IPSec endp - YYY.YYY.YYY.2 > > Net A - 192.168.45.129/32 > Net B - 192.168.45.130/32 > Net C - 192.168.40.8/29 > > Net 2 and Net 3 are setup to allow tunnel to Nets A,B and C. > > GW is FreeBSD gw01.xxxx.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE > #0 r274192 > IKEv1 etc. is handled by strongswan-5.2.0_1 > Left IPSec endpoint is a Clavister VPN GW. > > After a host on Net 3 has connected through the tunnel to > 192.168.45.129 via a NATed VMWare Fusion connection, traffic from > that host is received correctly at the GW on Net 3 (em1) but the > response from the GW is sent out via the DMZ interface em5. > Switching the host to Net 4 i.e. disconnecting the network cable and > starting the WiFi restores connectivity. > > Other hosts on Net 3 that has not communicated via the IPSec tunnel > is NOT affected. > > All routing seems to be correct on the GW so some other mechanism > must be at play. > > Any help appreciated. Could you please send us at least a dump of your SPD and routing configuration ? Yvan. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 10:26:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3A478B9; Tue, 18 Nov 2014 10:26:25 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [176.57.193.164]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.ismobile.com", Issuer "GlobalSign Domain Validation CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13FEEEF6; Tue, 18 Nov 2014 10:26:24 +0000 (UTC) Received: from mail.ismobile.com (localhost [127.0.0.1]) by dkim.mail.ismobile.com (Postfix) with ESMTP id 3056D2B54A4; Tue, 18 Nov 2014 10:26:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=+xKqSBh BHN529f3i6kSy3m4ENJA=; b=m6sK/3gOeYsLG88i7GSw8CoSlHzh8N41LyuSHlv cRI2bBf2AlpluJBlyeBUkAJbf4cfuUPaWXk1Dxhr1xF408pR2KY3XK2MDCVeu+BN ze7lRea9P4qk/cDB9j0UanVf5iM605dzfi90HSvR07tig4b5VCfM0edv25kdeWpT M2sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=d RHlZ0/YQxbUyGzi1pKiL+hOpGhGBpf0WvMQmNFAxfxFYn2NBcsZMOWzRIl8Wvo8X olw9huIk+jEoGCy7Lfbv2o7WgNiNEfJOpoQm6fG6RdTxac9cOHgKz88AwdFqeXGP sgqpVllH/JfQV3jwfBNTmHo2HpP3y5FBI0nR0XzoOI= Received: from [172.16.2.28] (glz-macbookpro.hq.ismobile.com [172.16.2.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 6E4162B54A1; Tue, 18 Nov 2014 10:26:21 +0000 (UTC) Date: Tue, 18 Nov 2014 11:26:19 +0100 From: =?UTF-8?Q?G=C3=B6ran_L=C3=B6wkrantz?= To: VANHULLEBUS Yvan Subject: Re: [MASSMAIL]Re: Problem with IPSec tunnel and normal routing Message-ID: <6F84B34B2AA9F9E37A9161FF@[172.16.2.28]> In-Reply-To: <20141118100739.GB18512@zeninc.net> References: <20141118100739.GB18512@zeninc.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=15409 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 10:26:25 -0000 --On 18 Nov 2014 11:07:40 +0100 VANHULLEBUS Yvan wrote: > Hi. > > > On Tue, Nov 18, 2014 at 10:52:50AM +0100, G?ran L?wkrantz wrote: >> We have a problem with a NanoBSD GW/Router that seems to get it's >> forwarding screwed up by an IPSec tunnel. >> >> +----+ +-------+ >> | | +----+ | | +-- A >> 2 -+ | | | | | | >> 3 -+ GW +-- DMZ --+ FW +--- Internet ---???? ---+ IPSec +----+-- B >> 4 -+ | | | | endp | | >> | | +----+ | | +-- C >> +----+ +-------+ >> >> Net 2 - em2 - 192.168.2.0/24 - servers, server-net switches. >> Net 3 - em1 - 192.168.3.0/24 - workstations, ws-net switches >> Net 4 - em0 - 192.168.4.0/24 - WiFi access points + VLAN switch >> >> DMZ - em5 - XXX.XXX.XXX.128/27 - DMZ and transfer net to outside. >> IPSec endp - YYY.YYY.YYY.2 >> >> Net A - 192.168.45.129/32 >> Net B - 192.168.45.130/32 >> Net C - 192.168.40.8/29 >> >> Net 2 and Net 3 are setup to allow tunnel to Nets A,B and C. >> >> GW is FreeBSD gw01.xxxx.com 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE >> # 0 r274192 >> IKEv1 etc. is handled by strongswan-5.2.0_1 >> Left IPSec endpoint is a Clavister VPN GW. >> >> After a host on Net 3 has connected through the tunnel to >> 192.168.45.129 via a NATed VMWare Fusion connection, traffic from >> that host is received correctly at the GW on Net 3 (em1) but the >> response from the GW is sent out via the DMZ interface em5. >> Switching the host to Net 4 i.e. disconnecting the network cable and >> starting the WiFi restores connectivity. >> >> Other hosts on Net 3 that has not communicated via the IPSec tunnel >> is NOT affected. >> >> All routing seems to be correct on the GW so some other mechanism >> must be at play. >> >> Any help appreciated. > > Could you please send us at least a dump of your SPD and routing > configuration ? > > > Yvan. > _______________________________________________ > netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 176.57.193.129 UGS em5 10.191.251.0/24 10.191.251.2 UGS tun0 10.191.251.1 link#12 UHS lo0 10.191.251.2 link#12 UH tun0 10.191.252.0/24 10.191.252.2 UGS tun1 10.191.252.1 link#13 UHS lo0 10.191.252.2 link#13 UH tun1 10.191.253.0/24 10.191.253.2 UGS tun2 10.191.253.1 link#14 UHS lo0 10.191.253.2 link#14 UH tun2 127.0.0.1 link#11 UH lo0 176.57.193.128/27 link#6 U em5 176.57.193.157 link#6 UHS lo0 176.57.193.157/32 link#6 U em5 176.57.193.158 link#6 UHS lo0 192.168.2.0/24 link#3 U em2 192.168.2.1 link#3 UHS lo0 192.168.3.0/24 link#2 U em1 192.168.3.1 link#2 UHS lo0 192.168.4.0/24 link#1 U em0 192.168.4.254 link#1 UHS lo0 192.168.5.0/24 link#4 U em3 192.168.5.254 link#4 UHS lo0 192.168.9.0/24 link#5 U em4 192.168.9.254 link#5 UHS lo0 192.168.40.8/29 176.57.193.129 US em5 192.168.45.129 176.57.193.129 UGHS em5 192.168.45.130 176.57.193.129 UGHS em5 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 default 2a00:f680:101:1::1 UGS em5 ::1 link#11 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2a00:f680:101:1::/64 link#6 U em5 2a00:f680:101:1::fffd link#6 UHS lo0 2a00:f680:101:1::fffe link#6 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em5/64 link#6 U em5 fe80::230:48ff:feb9:99c9%em5 link#6 UHS lo0 fe80::%lo0/64 link#11 U lo0 fe80::1%lo0 link#11 UHS lo0 fe80::%tun0/64 link#12 U tun0 fe80::21b:21ff:fe24:6248%tun0 link#12 UHS lo0 fe80::%tun1/64 link#13 U tun1 fe80::21b:21ff:fe24:6248%tun1 link#13 UHS lo0 fe80::%tun2/64 link#14 U tun2 fe80::21b:21ff:fe24:6248%tun2 link#14 UHS lo0 ff01::%em5/32 fe80::230:48ff:feb9:99c9%em5 U em5 ff01::%lo0/32 ::1 U lo0 ff01::%tun0/32 fe80::21b:21ff:fe24:6248%tun0 U tun0 ff01::%tun1/32 fe80::21b:21ff:fe24:6248%tun1 U tun1 ff01::%tun2/32 fe80::21b:21ff:fe24:6248%tun2 U tun2 ff02::/16 ::1 UGRS lo0 ff02::%em5/32 fe80::230:48ff:feb9:99c9%em5 U em5 ff02::%lo0/32 ::1 U lo0 ff02::%tun0/32 fe80::21b:21ff:fe24:6248%tun0 U tun0 ff02::%tun1/32 fe80::21b:21ff:fe24:6248%tun1 U tun1 ff02::%tun2/32 fe80::21b:21ff:fe24:6248%tun2 U tun2 root@gw01:/data/home/admglz # setkey -D No SAD entries. root@gw01:/data/home/admglz # setkey -DP 192.168.45.130[any] 192.168.2.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=84 seq=29 pid=51194 refcnt=1 192.168.40.8/29[any] 192.168.2.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=86 seq=28 pid=51194 refcnt=1 192.168.45.130[any] 192.168.3.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=88 seq=27 pid=51194 refcnt=1 192.168.40.8/29[any] 192.168.3.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=90 seq=26 pid=51194 refcnt=1 192.168.45.129[any] 10.191.251.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=92 seq=25 pid=51194 refcnt=1 192.168.45.130[any] 10.191.251.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=94 seq=24 pid=51194 refcnt=1 192.168.40.8/29[any] 10.191.251.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=96 seq=23 pid=51194 refcnt=1 192.168.45.129[any] 10.191.252.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=98 seq=22 pid=51194 refcnt=1 192.168.45.130[any] 10.191.252.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=100 seq=21 pid=51194 refcnt=1 192.168.40.8/29[any] 10.191.252.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=102 seq=20 pid=51194 refcnt=1 192.168.45.129[any] 10.191.253.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=104 seq=19 pid=51194 refcnt=1 192.168.45.130[any] 10.191.253.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=106 seq=18 pid=51194 refcnt=1 192.168.40.8/29[any] 10.191.253.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=108 seq=17 pid=51194 refcnt=1 192.168.45.129[any] 192.168.2.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 10:19:57 2014 lastused: Nov 18 10:19:57 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=112 seq=16 pid=51194 refcnt=1 192.168.45.129[any] 192.168.3.0/24[any] any in ipsec esp/tunnel/92.254.132.2-176.57.193.158/unique:1 created: Nov 18 11:09:30 2014 lastused: Nov 18 11:09:30 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=114 seq=15 pid=51194 refcnt=1 192.168.2.0/24[any] 192.168.45.130[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=83 seq=14 pid=51194 refcnt=1 192.168.2.0/24[any] 192.168.40.8/29[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=85 seq=13 pid=51194 refcnt=1 192.168.3.0/24[any] 192.168.45.130[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=87 seq=12 pid=51194 refcnt=1 192.168.3.0/24[any] 192.168.40.8/29[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=89 seq=11 pid=51194 refcnt=1 10.191.251.0/24[any] 192.168.45.129[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=91 seq=10 pid=51194 refcnt=1 10.191.251.0/24[any] 192.168.45.130[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=93 seq=9 pid=51194 refcnt=1 10.191.251.0/24[any] 192.168.40.8/29[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=95 seq=8 pid=51194 refcnt=1 10.191.252.0/24[any] 192.168.45.129[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=97 seq=7 pid=51194 refcnt=1 10.191.252.0/24[any] 192.168.45.130[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=99 seq=6 pid=51194 refcnt=1 10.191.252.0/24[any] 192.168.40.8/29[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=101 seq=5 pid=51194 refcnt=1 10.191.253.0/24[any] 192.168.45.129[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=103 seq=4 pid=51194 refcnt=1 10.191.253.0/24[any] 192.168.45.130[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=105 seq=3 pid=51194 refcnt=1 10.191.253.0/24[any] 192.168.40.8/29[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 09:49:44 2014 lastused: Nov 18 09:49:44 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=107 seq=2 pid=51194 refcnt=1 192.168.2.0/24[any] 192.168.45.129[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 10:19:57 2014 lastused: Nov 18 10:19:57 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=111 seq=1 pid=51194 refcnt=1 192.168.3.0/24[any] 192.168.45.129[any] any out ipsec esp/tunnel/176.57.193.158-92.254.132.2/unique:1 created: Nov 18 11:09:30 2014 lastused: Nov 18 11:09:30 2014 lifetime: 9223372036854775807(s) validtime: 0(s) spid=113 seq=0 pid=51194 refcnt=1 root@gw01:/data/home/admglz # ipsec statusall Status of IKE charon daemon (strongSwan 5.2.0, FreeBSD 10.1-PRERELEASE, amd64): uptime: 3 days, since Nov 15 09:32:27 2014 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5 loaded plugins: charon curl aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf xcbc cmac hmac attr kernel-pfkey kernel-pfroute resolve socket-default stroke updown eap-identity eap-md5 eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic whitelist addrblock Listening IP addresses: 192.168.4.254 192.168.3.1 192.168.2.1 192.168.5.254 192.168.9.254 176.57.193.158 2a00:f680:101:1::fffe 176.57.193.157 2a00:f680:101:1::fffd 10.191.251.1 10.191.252.1 10.191.253.1 Connections: net-net: 176.57.193.158...92.254.132.2 IKEv1 net-net: local: [176.57.193.158] uses pre-shared key authentication net-net: remote: [92.254.132.2] uses pre-shared key authentication net-net: child: 192.168.2.0/24 192.168.3.0/24 10.191.251.0/24 10.191.252.0/24 10.191.253.0/24 === 192.168.45.129/32 192.168.45.130/32 192.168.40.8/29 TUNNEL Routed Connections: net-net{1}: ROUTED, TUNNEL net-net{1}: 192.168.2.0/24 192.168.3.0/24 10.191.251.0/24 10.191.252.0/24 10.191.253.0/24 === 192.168.45.129/32 192.168.45.130/32 192.168.40.8/29 Security Associations (1 up, 0 connecting): net-net[6]: ESTABLISHED 72 minutes ago, 176.57.193.158[176.57.193.158]...92.254.132.2[92.254.132.2] net-net[6]: IKEv1 SPIs: c71206a4eb076dde_i 1587c4b0b11e1003_r*, pre-shared key reauthentication in 6 hours net-net[6]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536 /glz From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 10:46:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BDA2DFE for ; Tue, 18 Nov 2014 10:46:31 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCE16149 for ; Tue, 18 Nov 2014 10:46:30 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so17592479lbv.10 for ; Tue, 18 Nov 2014 02:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QtDA9rK9ZD5lPEGKNLxD/cL8+6JipPk7Og6M79jIAfs=; b=q5MkCZ/8N9yvrfXYwGsg90FowA/TN20Q7GJgBJaGvGjFwlkpxj7ExEH2nY2oUUdkvC hVavnhalFwnVYzNJMdM6g7ZVIcU2aPi/A6j64pPW4JC+K4MeWYNDu41EToHM39Co8gVP RJiA+oAwrgTdEeZ3nMgAGxxt0q5IgwHRihZ4aHq3Rq/36jCMxOEbbZWGimjyBs/TDEsU 4I8u4wuSaWleY7vxA8gynu1BR4gnccTSGMUJQM9Fla2VhaBSCSIsWDeKEFzvt95yanxg XlHOqIxn+QvYiAP7ZZfSM0AHPiuAfYt1wyKjBEYP9OkQz71V1RR1M8GydgoykKwH7x8E cD4g== X-Received: by 10.152.36.201 with SMTP id s9mr34861540laj.17.1416307589029; Tue, 18 Nov 2014 02:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.145.16 with HTTP; Tue, 18 Nov 2014 02:45:48 -0800 (PST) In-Reply-To: <5469FFD5.9070002@multiplay.co.uk> References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> <5469FFD5.9070002@multiplay.co.uk> From: Christer Solskogen Date: Tue, 18 Nov 2014 11:45:48 +0100 Message-ID: Subject: Re: ZFS pool creation from files leads to a crash To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: Bogdan SOLGA , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 10:46:31 -0000 On Mon, Nov 17, 2014 at 3:01 PM, Steven Hartland wrote: > I committed the fix for this earlier: > https://svnweb.freebsd.org/changeset/base/274619 > > How about stable/10? Should it go into releng/10.1 as well? -- chs From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 10:53:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7801B92 for ; Tue, 18 Nov 2014 10:53:18 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B39C223 for ; Tue, 18 Nov 2014 10:53:17 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xqg9j-0001hw-6C for freebsd-stable@freebsd.org; Tue, 18 Nov 2014 11:37:12 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Mountroot prompt with the new vt(4) console not working. References: Date: Tue, 18 Nov 2014 11:37:05 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=disabled version=3.3.2 X-Scan-Signature: a8ecdd0179e5342c74548fafd5461917 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 10:53:18 -0000 On Sat, 15 Nov 2014 13:03:38 +0100, Kimmo Paasiala wrote: > I'm not able to use the mountroot prompt with the new vt(4) console on > any of the systems I have, all of them either stable/10 or > releng/10.1. The problem is that I can't type anything at the prompt > or if I can the letters appear as garbage and they come out like one > character every five seconds. Is the mountroot prompt working for > anyone who is using the new vt(4) console? > > -Kimmo Not much reaction on this one. It can help if you tell more about your setup. - What kind of keyboard (USB or PS/2)? What country/language is the keyboard for? - GENERIC kernel or custom? - What video driver are you using with vt? - Any custom settings while booting? - etc. Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 10:53:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A4D0179 for ; Tue, 18 Nov 2014 10:53:31 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACDC4229 for ; Tue, 18 Nov 2014 10:53:30 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so3649803wgh.39 for ; Tue, 18 Nov 2014 02:53:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5EQ/jgv9t9QQh/w2YyMthI4fdldugRXOmMyVd/Xjsqs=; b=EVLFUhO6dXJoevlri+RDPdZn81wSvAfPJbtEWKcc6IV0B0m2q8QhTjqroqu2/MYcIM DWSKD1POuRt72FsYlbhvBueyXuAVhfNORElQcuzUUjerDx2R9AnZ+4w9X6Zaab2zzIiv oDJnn9o0xUrAHDIumaY5Kisz36HHjqhicncBXdaXQClgac0oFMNNpE6Em2Q9HpSk/2UQ IMsB7BNHCvFXI/YEPLHrcFhxMwxMX3hwa4FQJRFF99cQgQZibcJBbtPBN1brzyF76/JV lDXV1IydLH0qhsp/34cE7ghqdhv9NH9PzPGhVG6cF7JRPiUayhLpsLtZ1J8x4MGqcdMg HDDQ== X-Gm-Message-State: ALoCoQlS6TCb4qyz9kq18DCA4MHcCs8tLO76LP6yxXlEU5n1S2GuZ2/BPkrnjtrk99meSgAYM5jj X-Received: by 10.194.206.106 with SMTP id ln10mr47653818wjc.70.1416308002527; Tue, 18 Nov 2014 02:53:22 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id cq4sm11048418wjc.35.2014.11.18.02.53.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Nov 2014 02:53:21 -0800 (PST) Message-ID: <546B2526.4080302@multiplay.co.uk> Date: Tue, 18 Nov 2014 10:53:26 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christer Solskogen Subject: Re: ZFS pool creation from files leads to a crash References: <54685EB8.9050800@FreeBSD.org> <5468CD8C.7070500@multiplay.co.uk> <5469FFD5.9070002@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bogdan SOLGA , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 10:53:31 -0000 On 18/11/2014 10:45, Christer Solskogen wrote: > On Mon, Nov 17, 2014 at 3:01 PM, Steven Hartland > wrote: >> I committed the fix for this earlier: >> https://svnweb.freebsd.org/changeset/base/274619 >> >> > How about stable/10? Should it go into releng/10.1 as well? > Stable will be after the MFC timeout of 3 days releng/10.1 as been released so the only possibility for that would be a errata. Once its in stable/10 I'll touch base with re@ and see if they want to do that. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 11:04:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8089D358 for ; Tue, 18 Nov 2014 11:04:41 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10A6B346 for ; Tue, 18 Nov 2014 11:04:41 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id n3so1393079wiv.11 for ; Tue, 18 Nov 2014 03:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=6utp3hMWlwNRxt4KlyZG5CBVhOU7OLhnr6XNztsFjHE=; b=BsGtzNExz5kkUp7HWIz1SybvjsesclqW42YwOPj5DZD8L/ZclQamZnfOIyi39Uegrl li5Kg2NcI/USs6BE+dIS3foUKLsvCpsgHunqnX6yhgF0GrWANL+SEghmnLbeTloUWBKM iLNPNzr6YUTMkm8S1jI7BmZ/Z5wvYR2FFJTjAU15p8GKcwvjK7ftvTY/l2ngtHa2dtcY GLS7a6HI1MUd9RzHq+HiEOqc//9xk5O8WFoC3rRQGIJsH0VizPvrQQiU5yr+50RwEwgX vUNNr88lsssa7i77xYQP7qDnOyXtBh+Kxjy0ZSAmiw8A/mB7OsrGCGCWCmZl2euzU19a S7Pg== X-Received: by 10.194.175.67 with SMTP id by3mr46212754wjc.32.1416308678910; Tue, 18 Nov 2014 03:04:38 -0800 (PST) Received: from [192.168.1.145] (static-228-200-167-83.thenetworkfactory.nl. [83.167.200.228]) by mx.google.com with ESMTPSA id hk9sm55327693wjb.46.2014.11.18.03.04.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Nov 2014 03:04:38 -0800 (PST) Message-ID: <546B27C6.10403@gmail.com> Date: Tue, 18 Nov 2014 12:04:38 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Native ISCSI FreeBSD 10 stable Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 11:04:41 -0000 Hello all. I am using the ports based ISCSI target deamon from net/istgt. With this port I can get good speeds using my windows 7 machine, it reads and writes at 80 to 90 MB/s on a 1 GB network. If I switch to the native iscsi target using ctld I only get around 30 MB/s read speed, the write speed start high but then drops down to around 50MB half way and then it slowly drops to 40 till the end of the copy. You can see it drop slowly. This is with some iso files, and it is around 10 GB in total. Is there anything I can do to tune this up. regards Johan From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 13:37:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D3A0909 for ; Tue, 18 Nov 2014 13:37:36 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44D4D6C2 for ; Tue, 18 Nov 2014 13:37:36 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id im17so8649462vcb.27 for ; Tue, 18 Nov 2014 05:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0UhN1OPIEzD87AIwUq69wv0+UpCfkbLGECjEnWDZtWE=; b=M1i/fxmkW+uG3k8zpun8YD2VW/LJ3mocimbhjsE1sF3qt7N3gkOzXX1Q7aFc3pZ9DG ATlfmsLKZa3a+eCa4RnQDii6OtkAsW7MYO844s/Pd23sYBDUsjYnnajk2dtl/dX64mLA gSqnMLN6SRTMdc5PG2xK8iXYNY89sDCCUAJN0mjoCipVTZw83RAGEUF3hTVYq2TD0x5e dvD90OFAFoHoQTBZTPCb12ecfdk+GwjO+NSXJhIso2n/LlaUKAZtKGPtSZl20teDYn43 NSVsYHaozRRq5U86oXqPst50bYtRdj2zhWrNS/SpZvtqGkmvaWsxNWSv1vJHW07xTU45 adiw== MIME-Version: 1.0 X-Received: by 10.220.132.210 with SMTP id c18mr9792093vct.35.1416317855353; Tue, 18 Nov 2014 05:37:35 -0800 (PST) Received: by 10.31.142.77 with HTTP; Tue, 18 Nov 2014 05:37:35 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 15:37:35 +0200 Message-ID: Subject: Re: Mountroot prompt with the new vt(4) console not working. From: Kimmo Paasiala To: Ronald Klop Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 13:37:36 -0000 On Tue, Nov 18, 2014 at 12:37 PM, Ronald Klop wrote: > On Sat, 15 Nov 2014 13:03:38 +0100, Kimmo Paasiala > wrote: > >> I'm not able to use the mountroot prompt with the new vt(4) console on >> any of the systems I have, all of them either stable/10 or >> releng/10.1. The problem is that I can't type anything at the prompt >> or if I can the letters appear as garbage and they come out like one >> character every five seconds. Is the mountroot prompt working for >> anyone who is using the new vt(4) console? >> >> -Kimmo > > > Not much reaction on this one. It can help if you tell more about your > setup. > - What kind of keyboard (USB or PS/2)? What country/language is the keyboard > for? > - GENERIC kernel or custom? > - What video driver are you using with vt? > - Any custom settings while booting? > - etc. > > Regards, > Ronald. > _______________________________________________ It's a PS/2 keyboard. Only the default VGA driver is used with vt(4). These are my loader.conf(5) settings on one of my systems: loader_logo="beastie" hw.usb.no_pf=1 kern.cam.ada.legacy_aliases=0 kern.vty=vt kern.geom.label.gptid.enable=0 This particular system is a firewall based on rather old Jetway J7F2WE1F2E Mini-ITX motherboard: http://www.jetwaycomputer.com/J7F2.html I don't exactly need vt(4) console on my systems because they are just firewalls and servers so no X anywhere but I'd like to know if other people have the same problem and if it's a problem with the vt(4) driver or something peculiar to my systems, BIOS problem or something else. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 13:54:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 481C1156 for ; Tue, 18 Nov 2014 13:54:19 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2A81916 for ; Tue, 18 Nov 2014 13:54:18 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id la4so8737448vcb.33 for ; Tue, 18 Nov 2014 05:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hmTMhKBkZGC6Ah+NPKQ4bteublZ06moSlOkzaxTlrBg=; b=Nj7xhRYHnfX+XYbtGus6CpQ1cfchsyeuI+CYK4zidiwRK+mgW58lcpzcIFSxohwj1/ klvgLK2fQWvtIt8Bl4CwJFB3hZ26EkXir30Bs5Shr9AyPF3vE3CiWbwOFJUlC8AwliJD gVV/gaasJlZtq4ZcpK9wVjyN6IBcgp3uYeUwMStijE0V7cEWKFD7RBCksJtRNham7amI i6kZOJSac7mDF9qu+HL16OI7Z55RrPVj07BZvzNQKoBrv6EbwVoXOHOSFucluculaWjh Lf2iXoUfyPRSxhwBcbk9nigEYB8MTQ2RsX1WaXgLAfCM8Vtzx3NfVIp0P/zNEadIDDQR 6whQ== MIME-Version: 1.0 X-Received: by 10.52.26.45 with SMTP id i13mr135550vdg.93.1416318858161; Tue, 18 Nov 2014 05:54:18 -0800 (PST) Received: by 10.31.142.77 with HTTP; Tue, 18 Nov 2014 05:54:18 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 15:54:18 +0200 Message-ID: Subject: Re: Mountroot prompt with the new vt(4) console not working. From: Kimmo Paasiala To: Ronald Klop Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 13:54:19 -0000 On Tue, Nov 18, 2014 at 3:37 PM, Kimmo Paasiala wrote: > On Tue, Nov 18, 2014 at 12:37 PM, Ronald Klop wrote: >> On Sat, 15 Nov 2014 13:03:38 +0100, Kimmo Paasiala >> wrote: >> >>> I'm not able to use the mountroot prompt with the new vt(4) console on >>> any of the systems I have, all of them either stable/10 or >>> releng/10.1. The problem is that I can't type anything at the prompt >>> or if I can the letters appear as garbage and they come out like one >>> character every five seconds. Is the mountroot prompt working for >>> anyone who is using the new vt(4) console? >>> >>> -Kimmo >> >> >> Not much reaction on this one. It can help if you tell more about your >> setup. >> - What kind of keyboard (USB or PS/2)? What country/language is the keyboard >> for? >> - GENERIC kernel or custom? >> - What video driver are you using with vt? >> - Any custom settings while booting? >> - etc. >> >> Regards, >> Ronald. >> _______________________________________________ > > > It's a PS/2 keyboard. Only the default VGA driver is used with vt(4). > These are my loader.conf(5) settings on one of my systems: > > loader_logo="beastie" > hw.usb.no_pf=1 > kern.cam.ada.legacy_aliases=0 > kern.vty=vt > kern.geom.label.gptid.enable=0 > > This particular system is a firewall based on rather old Jetway > J7F2WE1F2E Mini-ITX motherboard: > > http://www.jetwaycomputer.com/J7F2.html > > > I don't exactly need vt(4) console on my systems because they are just > firewalls and servers so no X anywhere but I'd like to know if other > people have the same problem and if it's a problem with the vt(4) > driver or something peculiar to my systems, BIOS problem or something > else. > > -Kimmo Just tested mountroot prompt with vt(4) on an AMD64 VirtualBox virtual machine that has releng/10.1, not the final release though. Same exact problem. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 15:49:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B21643D for ; Tue, 18 Nov 2014 15:49:16 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26E548C4 for ; Tue, 18 Nov 2014 15:49:15 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sAIFnEQt083320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Nov 2014 08:49:14 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sAIFnDRs083317; Tue, 18 Nov 2014 08:49:13 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 18 Nov 2014 08:49:13 -0700 (MST) From: Warren Block To: Kimmo Paasiala Subject: Re: Mountroot prompt with the new vt(4) console not working. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 18 Nov 2014 08:49:14 -0700 (MST) Cc: "freebsd-stable@freebsd.org" , Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 15:49:16 -0000 On Tue, 18 Nov 2014, Kimmo Paasiala wrote: > It's a PS/2 keyboard. Only the default VGA driver is used with vt(4). > These are my loader.conf(5) settings on one of my systems: > > loader_logo="beastie" > hw.usb.no_pf=1 > kern.cam.ada.legacy_aliases=0 > kern.vty=vt > kern.geom.label.gptid.enable=0 Does it change if hw.vga.textmode=1 is added? From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 16:17:56 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02FBA1BE for ; Tue, 18 Nov 2014 16:17:56 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 778F5C6C for ; Tue, 18 Nov 2014 16:17:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAIGHPIV004003 for ; Tue, 18 Nov 2014 19:17:25 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 18 Nov 2014 19:17:25 +0300 (MSK) From: Dmitry Morozovsky To: stable@FreeBSD.org Subject: stab;e/10 panic under disk load Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Nov 2014 19:17:25 +0300 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 16:17:56 -0000 Dear colleagues, my backup server after updrade to frest stable/10 start panicing on heavy disk load like rsync at FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 12:15:24 MSK 2014 marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 cpuid = 0 KDB: stack backtrace: #0 0xffffffff80964fa0 at kdb_backtrace+0x60 #1 0xffffffff8092a085 at panic+0x155 #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e #3 0xffffffff80b9fad7 at vm_fault+0x77 #4 0xffffffff80d2861c at trap_pfault+0x19c #5 0xffffffff80d27dea at trap+0x47a #6 0xffffffff80d0db92 at calltrap+0x8 #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 #11 0xffffffff809d68cc at kern_getdirentries+0x21c #12 0xffffffff809d6688 at sys_getdirentries+0x28 #13 0xffffffff80d28da1 at amd64_syscall+0x351 #14 0xffffffff80d0de7b at Xfast_syscall+0xfb Uptime: 1m51s Unfortunately it's ZFS only, so I have no space to white panic dump. I'm now trying to rebuild kernel with debugger turned on, as luckily I have working console@SOL... Any preliminary hints? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 16:26:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4652776 for ; Tue, 18 Nov 2014 16:26:44 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99F5AEE9 for ; Tue, 18 Nov 2014 16:26:44 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id im6so5891674vcb.25 for ; Tue, 18 Nov 2014 08:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=atiNCEO0fjQxAyyqcptJsbhfwJNOGWDb/wyHe0pv0s4=; b=oFo2PEUZ+PxWqQM5kJNQS2JPH2LpZ47DLfmgihgBZ+aK/A/+qiGZQ5gkQC5nNYwqaE A3aZA0dZBrZ2Ij1w5sPhm6cfoHNHVW+GqKsDJm7x2xgKR/evjd0TPCq0BuHL5g7ygq0Z FpsQTjrkzOlm+aifB1N6ipuI8dRlYdmw7YVUnwwinxEnpy22ptlTlzabAQrXkjJUaSpZ feYe6tsEnSsha9c5/1BzmdsPjFRGOf8vzTS73LNA+AG00rVRMTO7VRu/AYoli51EOUwT 7Kx9Ocfg6TcuiIKTP9y4tmCzOm6k/dS8j39kLmjg6eBfUgtgaRuKYf26x/q3tHkcc9g2 W1hA== MIME-Version: 1.0 X-Received: by 10.221.41.193 with SMTP id tv1mr851434vcb.72.1416328003702; Tue, 18 Nov 2014 08:26:43 -0800 (PST) Received: by 10.31.142.77 with HTTP; Tue, 18 Nov 2014 08:26:43 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 18:26:43 +0200 Message-ID: Subject: Re: Mountroot prompt with the new vt(4) console not working. From: Kimmo Paasiala To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" , Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 16:26:45 -0000 On Tue, Nov 18, 2014 at 5:49 PM, Warren Block wrote: > On Tue, 18 Nov 2014, Kimmo Paasiala wrote: > >> It's a PS/2 keyboard. Only the default VGA driver is used with vt(4). >> These are my loader.conf(5) settings on one of my systems: >> >> loader_logo="beastie" >> hw.usb.no_pf=1 >> kern.cam.ada.legacy_aliases=0 >> kern.vty=vt >> kern.geom.label.gptid.enable=0 > > > Does it change if > > hw.vga.textmode=1 > > is added? No difference. What is interesting is that I can hear the fans on my machine (mac mini 2011 model) pick up speed when I'm stuck at the mountroot prompt unable to type anything as if something was running in a very tight busy loop. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 16:57:04 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03F899E1; Tue, 18 Nov 2014 16:57:04 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7072F38E; Tue, 18 Nov 2014 16:57:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAIGuefU004635; Tue, 18 Nov 2014 19:56:40 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 18 Nov 2014 19:56:40 +0300 (MSK) From: Dmitry Morozovsky To: stable@freebsd.org Subject: ZFS panic: [Re: stable/10 panic under disk load] In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Nov 2014 19:56:40 +0300 (MSK) Cc: smh@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 16:57:04 -0000 On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > my backup server after updrade to frest stable/10 > > start panicing on heavy disk load like rsync at Yes, it is reproducible easy and now I'm at ddb prompt with cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 panic() at panic+0x43/frame 0xfffffe0860864eb0 vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 trap() at trap+0x47a/frame 0xfffffe08608653f0 calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp = 0xfffffe0860865500 --- zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame 0xfffffe0860865500 fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570 zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600 zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840 VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970 sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp = 0x7fffffffb538, rbp = 0x7fffffffb560 --- KDB: enter: panic [ thread pid 1167 tid 100461 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> Can I obtain somthing useful from here? I'm afraid it's not easy to attach additional disk for crash dumps to this server... > > FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 > 12:15:24 MSK 2014 > marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 > > > panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80964fa0 at kdb_backtrace+0x60 > #1 0xffffffff8092a085 at panic+0x155 > #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e > #3 0xffffffff80b9fad7 at vm_fault+0x77 > #4 0xffffffff80d2861c at trap_pfault+0x19c > #5 0xffffffff80d27dea at trap+0x47a > #6 0xffffffff80d0db92 at calltrap+0x8 > #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e > #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 > #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 > #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 > #11 0xffffffff809d68cc at kern_getdirentries+0x21c > #12 0xffffffff809d6688 at sys_getdirentries+0x28 > #13 0xffffffff80d28da1 at amd64_syscall+0x351 > #14 0xffffffff80d0de7b at Xfast_syscall+0xfb > Uptime: 1m51s > > Unfortunately it's ZFS only, so I have no space to white panic dump. > > I'm now trying to rebuild kernel with debugger turned on, as luckily I have > working console@SOL... > > Any preliminary hints? > > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 17:03:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30F21D18 for ; Tue, 18 Nov 2014 17:03:19 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8FB367D for ; Tue, 18 Nov 2014 17:03:18 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ij19so7337633vcb.22 for ; Tue, 18 Nov 2014 09:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a1JuV33rLNAdL5fj2bn3TLcIcGaoIYvfC6PHuckfKwQ=; b=idxejLokwiC6lfqfgfjqH4BCj90dVIsvapJrcFqxoLNF5f5UF2UY/aUkT66nh+iSTb 0gGBV+W99dn38ZxozPuFJVRYHm4grMhLEHb+r2XYa5OvYbVML/hwgT5NcgFsYSKb47K2 GuKULb28SGfK6P1Hgi8b/4QkL6Q/wzKkoc0+ZdICttUsWZ84lai9syXWretKAgYPEJYI +OCV8+tmaKmLyKNSrVV2qsW7p75iam9cfXX6OIyOli9ZuhIRFnUk3o0a0Ul+K9TSv763 5imx8421M2lFDgR4a1exAQECnNIaUEwUMFIsabhqeyIWXBhwQPCMsZO1KGMGnZgdKun5 75LA== MIME-Version: 1.0 X-Received: by 10.52.163.202 with SMTP id yk10mr27403133vdb.14.1416330197902; Tue, 18 Nov 2014 09:03:17 -0800 (PST) Received: by 10.31.142.77 with HTTP; Tue, 18 Nov 2014 09:03:17 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 19:03:17 +0200 Message-ID: Subject: Re: Mountroot prompt with the new vt(4) console not working. From: Kimmo Paasiala To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" , Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 17:03:19 -0000 On Tue, Nov 18, 2014 at 6:26 PM, Kimmo Paasiala wrote: > On Tue, Nov 18, 2014 at 5:49 PM, Warren Block wrote: >> On Tue, 18 Nov 2014, Kimmo Paasiala wrote: >> >>> It's a PS/2 keyboard. Only the default VGA driver is used with vt(4). >>> These are my loader.conf(5) settings on one of my systems: >>> >>> loader_logo="beastie" >>> hw.usb.no_pf=1 >>> kern.cam.ada.legacy_aliases=0 >>> kern.vty=vt >>> kern.geom.label.gptid.enable=0 >> >> >> Does it change if >> >> hw.vga.textmode=1 >> >> is added? > > No difference. What is interesting is that I can hear the fans on my > machine (mac mini 2011 model) pick up speed when I'm stuck at the > mountroot prompt unable to type anything as if something was running > in a very tight busy loop. > > -Kimmo The Mac Mini in question is running the VirtualBox VM in case you're wondering. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 17:14:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A21D2B32 for ; Tue, 18 Nov 2014 17:14:39 +0000 (UTC) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5BEDE818 for ; Tue, 18 Nov 2014 17:14:38 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 522B721D4E for ; Tue, 18 Nov 2014 17:14:37 +0000 (GMT) Received: from awontroba.plus.com (HELO swelter.hanley.stade.co.uk) (81.174.163.201) (smtp-auth username postmaster%pop3.stade.co.uk, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Tue, 18 Nov 2014 17:14:37 +0000 Received: from swelter.hanley.stade.co.uk (localhost [127.0.0.1]) by swelter.hanley.stade.co.uk (8.14.9/8.14.9) with ESMTP id sAIHE1uY008058 for ; Tue, 18 Nov 2014 17:14:01 GMT (envelope-from aw1@swelter.hanley.stade.co.uk) Received: (from aw1@localhost) by swelter.hanley.stade.co.uk (8.14.9/8.14.9/Submit) id sAIHE1dC008057 for freebsd-stable@freebsd.org; Tue, 18 Nov 2014 17:14:01 GMT (envelope-from aw1) Date: Tue, 18 Nov 2014 17:14:01 +0000 From: Adrian Wontroba To: "freebsd-stable@freebsd.org" Subject: Re: best overall upgrade from 8.x? Message-ID: <20141118171400.GC1995@swelter.hanley.stade.co.uk> Reply-To: aw1@stade.co.uk References: <54673CA1.5020008@netfence.it> <20141115125347.GC16633@swelter.hanley.stade.co.uk> <971085e211564c84a0460ca945eda837@ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.1-STABLE Organization: Oh dear, I've joined one again. User-Agent: Mutt/1.5.22 (2013-10-16) X-Gradwell-MongoId: 546b7e7d.3985-3146-2 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: postmaster@pop3.stade.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 17:14:39 -0000 On Mon, Nov 17, 2014 at 10:13:11PM -0800, Kevin Oberman wrote: > > make delete-old > This can be a bit painful as you are prompted for every file. I suggest > "make check-old" and then "rm -rf" any directories listed as ready for > deletion. direcctories are listed near the end, just before libs. yes | make delete-old Answers all those delete prompts with 'y'. Do not delete old libraries with make delete-old-libs before you have upgraded all your ports. The results can be painful. BTDT. -- Adrian Wontroba From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 17:38:58 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2705648E for ; Tue, 18 Nov 2014 17:38:58 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A61B9A4D for ; Tue, 18 Nov 2014 17:38:56 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id gm9so3707698lab.18 for ; Tue, 18 Nov 2014 09:38:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=5mUE6Muz8B3RnP31ug3w+jIAdmqpDCTxElV9FfDRXeI=; b=mV50ddULevq6H9CdSHSTfcSfvT9uOe+hx34SItxxRTtdUieGJDuRD2TZd9Sv3B0Yqe YLV7iDBc5gPCFL+aDwSHfXtdVqDNEm8VTbUbVabETW0kjfi3KnaC0HzUaEAbwwbmEFxX xem/BVfUC87ouatz8jQATa9LifiXbAHR4V8fJPr0TeVyzZz/IfvdFf7q6OMFsPil/wYn 2NEDKwe8axTrsCWqRYeVSewLYfiwRFAbBoPEP+RDWcVYCgodQ/WaexMVmouZTrlMTUO2 Uf9jnTyD4zIZjjrc6Ajjjthl37JfyYwVAzC79MgfWxQ2Ght6Pixy4yI+Cgyb0jC2bBGT nr8w== X-Gm-Message-State: ALoCoQmqvVJ+/DiVUw+qjG4CKRt5OcS83hwhf9q7y7I3TJPv/818kuXcelfCwLJO7J4bRJp9uy9s X-Received: by 10.152.5.6 with SMTP id o6mr37409922lao.8.1416332328838; Tue, 18 Nov 2014 09:38:48 -0800 (PST) From: Steven Hartland Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Tue, 18 Nov 2014 17:38:51 +0000 Message-ID: <-7425247475772590723@unknownmsgid> Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 Cc: "stable@freebsd.org" , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 17:38:58 -0000 Can u plug a usb drive in to get a dump? > On 18 Nov 2014, at 16:57, Dmitry Morozovsky wrote: > >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: >> >> my backup server after updrade to frest stable/10 >> >> start panicing on heavy disk load like rsync at > > Yes, it is reproducible easy and now I'm at ddb prompt with > > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 > panic() at panic+0x43/frame 0xfffffe0860864eb0 > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 > trap() at trap+0x47a/frame 0xfffffe08608653f0 > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp = > 0xfffffe0860865500 --- > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame > 0xfffffe0860865500 > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570 > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600 > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840 > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 > kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970 > sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp = > 0x7fffffffb538, rbp = 0x7fffffffb560 --- > KDB: enter: panic > [ thread pid 1167 tid 100461 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> > > Can I obtain somthing useful from here? I'm afraid it's not easy to attach > additional disk for crash dumps to this server... > > >> >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 >> 12:15:24 MSK 2014 >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 >> >> >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 >> #1 0xffffffff8092a085 at panic+0x155 >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e >> #3 0xffffffff80b9fad7 at vm_fault+0x77 >> #4 0xffffffff80d2861c at trap_pfault+0x19c >> #5 0xffffffff80d27dea at trap+0x47a >> #6 0xffffffff80d0db92 at calltrap+0x8 >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb >> Uptime: 1m51s >> >> Unfortunately it's ZFS only, so I have no space to white panic dump. >> >> I'm now trying to rebuild kernel with debugger turned on, as luckily I have >> working console@SOL... >> >> Any preliminary hints? >> >> > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 18:00:29 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC313940; Tue, 18 Nov 2014 18:00:29 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68D35C79; Tue, 18 Nov 2014 17:59:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAIHxZX0005795; Tue, 18 Nov 2014 20:59:35 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 18 Nov 2014 20:59:35 +0300 (MSK) From: Dmitry Morozovsky To: Steven Hartland Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] In-Reply-To: <-7425247475772590723@unknownmsgid> Message-ID: References: <-7425247475772590723@unknownmsgid> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Nov 2014 20:59:35 +0300 (MSK) Cc: "stable@freebsd.org" , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 18:00:30 -0000 On Tue, 18 Nov 2014, Steven Hartland wrote: > Can u plug a usb drive in to get a dump? Hm, will it work over USB stack? I can try this. BTW: it seems some internal ZFS locking trouble exists, as trere are 3 cases: pool/R/fs1 mounted as /fs1 pool/R/fs2 pool/R/fs3 tar cf - /fs1 >/dev/null works ok tar cf - /fs2 >/dev/null works ok rsync -avHP /fs1/ /fs2/ panics in few minutes will try to configure dump to USB SATA > > > > On 18 Nov 2014, at 16:57, Dmitry Morozovsky wrote: > > > >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > >> > >> my backup server after updrade to frest stable/10 > >> > >> start panicing on heavy disk load like rsync at > > > > Yes, it is reproducible easy and now I'm at ddb prompt with > > > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 > > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 > > panic() at panic+0x43/frame 0xfffffe0860864eb0 > > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 > > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 > > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 > > trap() at trap+0x47a/frame 0xfffffe08608653f0 > > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 > > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp = > > 0xfffffe0860865500 --- > > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame > > 0xfffffe0860865500 > > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570 > > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600 > > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840 > > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 > > kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970 > > sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0 > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 > > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp = > > 0x7fffffffb538, rbp = 0x7fffffffb560 --- > > KDB: enter: panic > > [ thread pid 1167 tid 100461 ] > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > db> > > > > Can I obtain somthing useful from here? I'm afraid it's not easy to attach > > additional disk for crash dumps to this server... > > > > > >> > >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 > >> 12:15:24 MSK 2014 > >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 > >> > >> > >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 > >> cpuid = 0 > >> KDB: stack backtrace: > >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 > >> #1 0xffffffff8092a085 at panic+0x155 > >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e > >> #3 0xffffffff80b9fad7 at vm_fault+0x77 > >> #4 0xffffffff80d2861c at trap_pfault+0x19c > >> #5 0xffffffff80d27dea at trap+0x47a > >> #6 0xffffffff80d0db92 at calltrap+0x8 > >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e > >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 > >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 > >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 > >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c > >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 > >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 > >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb > >> Uptime: 1m51s > >> > >> Unfortunately it's ZFS only, so I have no space to white panic dump. > >> > >> I'm now trying to rebuild kernel with debugger turned on, as luckily I have > >> working console@SOL... > >> > >> Any preliminary hints? > >> > >> > > > > -- > > Sincerely, > > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > [ FreeBSD committer: marck@FreeBSD.org ] > > ------------------------------------------------------------------------ > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > > ------------------------------------------------------------------------ > _______________________________________________ > 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" > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 18:35:01 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7005431C; Tue, 18 Nov 2014 18:35:01 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF12BCE; Tue, 18 Nov 2014 18:35:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAIIYbss006727; Tue, 18 Nov 2014 21:34:37 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 18 Nov 2014 21:34:37 +0300 (MSK) From: Dmitry Morozovsky To: Steven Hartland Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] In-Reply-To: Message-ID: References: <-7425247475772590723@unknownmsgid> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 18 Nov 2014 21:34:37 +0300 (MSK) Cc: "stable@freebsd.org" , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 18:35:01 -0000 On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > On Tue, 18 Nov 2014, Steven Hartland wrote: > > > Can u plug a usb drive in to get a dump? > > Hm, will it work over USB stack? I can try this. > > BTW: it seems some internal ZFS locking trouble exists, as trere are 3 cases: > > pool/R/fs1 mounted as /fs1 > pool/R/fs2 > pool/R/fs3 > > tar cf - /fs1 >/dev/null works ok > tar cf - /fs2 >/dev/null works ok > rsync -avHP /fs1/ /fs2/ panics in few minutes > > will try to configure dump to USB SATA wow, it works ;) not on the first trial, but anyway, here we go: #0 doadump (textdump=1621911824) at pcpu.h:219 #1 0xffffffff803471d5 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:568 #2 0xffffffff80346ebd in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80346c34 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80349580 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff80940cd9 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656 #6 0xffffffff80ce8ca3 in trap (frame=0xfffffe0860ac6d40) at /usr/src/sys/amd64/amd64/trap.c:556 #7 0xffffffff80ccf492 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #8 0xffffffff8094043e in kdb_enter (why=0xffffffff80f5b27c "panic", msg=) at cpufunc.h:63 #9 0xffffffff80908f76 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:752 #10 0xffffffff80908fe3 in panic (fmt=0xffffffff8154f850 "\004") at /usr/src/sys/kern/kern_shutdown.c:688 #11 0xffffffff80b64502 in vm_fault_hold (map=, vaddr=, fault_type=, fault_flags=, m_hold=) at /usr/src/sys/vm/vm_fault.c:341 #12 0xffffffff80b62b87 in vm_fault (map=0xfffff80002000000, vaddr=, fault_type=1 '\001', fault_flags=128) at /usr/src/sys/vm/vm_fault.c:281 #13 0xffffffff80ce9551 in trap_pfault (frame=0xfffffe0860ac7400, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:752 #14 0xffffffff80ce8cba in trap (frame=0xfffffe0860ac7400) at /usr/src/sys/amd64/amd64/trap.c:440 #15 0xffffffff80ccf492 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 #17 0xffffffff81b688ee in fzap_cursor_retrieve (zap=0xfffff8001676ce80, zc=0xfffffe0860ac77d8, za=0xfffffe0860ac76c0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1190 #18 0xffffffff81b6dc97 in zap_cursor_retrieve (zc=0xfffffe0860ac77d8, za=0xfffffe0860ac76c0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 #19 0xffffffff81ba8f16 in zfs_freebsd_readdir (ap=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2565 #20 0xffffffff80e03967 in VOP_READDIR_APV (vop=, a=) at vnode_if.c:1821 #21 0xffffffff809b1d1c in kern_getdirentries (td=0xfffff80025ff1490, fd=, buf=0x801428000
, count=, basep=0xfffffe0860ac7990, residp=0x0) at vnode_if.h:758 #22 0xffffffff809b1ad8 in sys_getdirentries (td=0xfffff801bd6ec880, uap=0xfffffe0860ac7a40) at /usr/src/sys/kern/vfs_syscalls.c:4030 #23 0xffffffff80ce9aca in amd64_syscall (td=0xfffff80025ff1490, traced=0) at subr_syscall.c:134 #24 0xffffffff80ccf77b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #25 0x000000080091043a in ?? () #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 466 if (HCD_GTEQ(le->le_hash, le->le_cd, h, cd) && (kgdb) p *le->le_hash No symbol "le" in current context. (kgdb) p le No symbol "le" in current context. (kgdb) p h $1 = 1441072784640835584 (kgdb) p *h Cannot access memory at address 0x13ffb81000000000 (kgdb) p cd $2 = 1 where now? > > > > > > > > On 18 Nov 2014, at 16:57, Dmitry Morozovsky wrote: > > > > > >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > >> > > >> my backup server after updrade to frest stable/10 > > >> > > >> start panicing on heavy disk load like rsync at > > > > > > Yes, it is reproducible easy and now I'm at ddb prompt with > > > > > > cpuid = 0 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60 > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 > > > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 > > > panic() at panic+0x43/frame 0xfffffe0860864eb0 > > > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 > > > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 > > > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 > > > trap() at trap+0x47a/frame 0xfffffe08608653f0 > > > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 > > > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp = > > > 0xfffffe0860865500 --- > > > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame > > > 0xfffffe0860865500 > > > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570 > > > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600 > > > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840 > > > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 > > > kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970 > > > sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0 > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 > > > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp = > > > 0x7fffffffb538, rbp = 0x7fffffffb560 --- > > > KDB: enter: panic > > > [ thread pid 1167 tid 100461 ] > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > db> > > > > > > Can I obtain somthing useful from here? I'm afraid it's not easy to attach > > > additional disk for crash dumps to this server... > > > > > > > > >> > > >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 > > >> 12:15:24 MSK 2014 > > >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 > > >> > > >> > > >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 > > >> cpuid = 0 > > >> KDB: stack backtrace: > > >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 > > >> #1 0xffffffff8092a085 at panic+0x155 > > >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e > > >> #3 0xffffffff80b9fad7 at vm_fault+0x77 > > >> #4 0xffffffff80d2861c at trap_pfault+0x19c > > >> #5 0xffffffff80d27dea at trap+0x47a > > >> #6 0xffffffff80d0db92 at calltrap+0x8 > > >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e > > >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 > > >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 > > >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 > > >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c > > >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 > > >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 > > >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb > > >> Uptime: 1m51s > > >> > > >> Unfortunately it's ZFS only, so I have no space to white panic dump. > > >> > > >> I'm now trying to rebuild kernel with debugger turned on, as luckily I have > > >> working console@SOL... > > >> > > >> Any preliminary hints? > > >> > > >> > > > > > > -- > > > Sincerely, > > > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > > [ FreeBSD committer: marck@FreeBSD.org ] > > > ------------------------------------------------------------------------ > > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > > > ------------------------------------------------------------------------ > > _______________________________________________ > > 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" > > > > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 18:56:40 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1390A841; Tue, 18 Nov 2014 18:56:40 +0000 (UTC) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C14422FA; Tue, 18 Nov 2014 18:56:39 +0000 (UTC) Received: by mail-yk0-f177.google.com with SMTP id 9so5317755ykp.22 for ; Tue, 18 Nov 2014 10:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=A268tQY1kcFyhkx9I0I/0XOHFuw4xeUtH5LdsCAjUGY=; b=Eb6uhfi78mT9XrRXwHgcoexXK05bTy91d6coKVd0dClEvVs/Ip1/xLyw5K1RoxPhGY 4aDzst4qKVknJMitmsbLGRizzOpremz2J6qGcy5fbZXuFmVkAiYv3tXL3zM2Y8Kr/gFE yrpkaVFbITaPNqVQRibtejiFpsXevjuSarSU1sTCXXPyRCLu59/IGyJUxTlpIFxIQpIe uiTfZO/ieAab1yXITZQnRIx0ea2J+tujDhnZ8qUoEwgmp/JbWIbM3etZ652UBDLV3GYs rA+zfIyKNFucIQZmIBUh09bEGiyaReqAG1NNBFZGUFeNV+FZ4i+4gY+u/j5PSTIyG4p3 qVFQ== MIME-Version: 1.0 X-Received: by 10.236.203.114 with SMTP id e78mr11383123yho.47.1416336998875; Tue, 18 Nov 2014 10:56:38 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Tue, 18 Nov 2014 10:56:38 -0800 (PST) In-Reply-To: References: <-7425247475772590723@unknownmsgid> Date: Tue, 18 Nov 2014 10:56:38 -0800 X-Google-Sender-Auth: furvJ45cOUBn_i4bNEAD8z8OJnw Message-ID: Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] From: "K. Macy" To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 Cc: "stable@freebsd.org" , Steven Hartland , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 18:56:40 -0000 On Tue, Nov 18, 2014 at 9:59 AM, Dmitry Morozovsky wrote: > On Tue, 18 Nov 2014, Steven Hartland wrote: > >> Can u plug a usb drive in to get a dump? > > Hm, will it work over USB stack? I can try this. > > BTW: it seems some internal ZFS locking trouble exists, as trere are 3 cases: > > pool/R/fs1 mounted as /fs1 > pool/R/fs2 > pool/R/fs3 > > tar cf - /fs1 >/dev/null works ok > tar cf - /fs2 >/dev/null works ok > rsync -avHP /fs1/ /fs2/ panics in few minutes > > will try to configure dump to USB SATA > Are you using extended attributes at all? -K >> >> > On 18 Nov 2014, at 16:57, Dmitry Morozovsky wrote: >> > >> >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: >> >> >> >> my backup server after updrade to frest stable/10 >> >> >> >> start panicing on heavy disk load like rsync at >> > >> > Yes, it is reproducible easy and now I'm at ddb prompt with >> > >> > cpuid = 0 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60 >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 >> > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 >> > panic() at panic+0x43/frame 0xfffffe0860864eb0 >> > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 >> > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 >> > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 >> > trap() at trap+0x47a/frame 0xfffffe08608653f0 >> > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 >> > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp = >> > 0xfffffe0860865500 --- >> > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame >> > 0xfffffe0860865500 >> > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570 >> > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600 >> > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840 >> > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 >> > kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970 >> > sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0 >> > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 >> > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp = >> > 0x7fffffffb538, rbp = 0x7fffffffb560 --- >> > KDB: enter: panic >> > [ thread pid 1167 tid 100461 ] >> > Stopped at kdb_enter+0x3e: movq $0,kdb_why >> > db> >> > >> > Can I obtain somthing useful from here? I'm afraid it's not easy to attach >> > additional disk for crash dumps to this server... >> > >> > >> >> >> >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 >> >> 12:15:24 MSK 2014 >> >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 >> >> >> >> >> >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 >> >> cpuid = 0 >> >> KDB: stack backtrace: >> >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 >> >> #1 0xffffffff8092a085 at panic+0x155 >> >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e >> >> #3 0xffffffff80b9fad7 at vm_fault+0x77 >> >> #4 0xffffffff80d2861c at trap_pfault+0x19c >> >> #5 0xffffffff80d27dea at trap+0x47a >> >> #6 0xffffffff80d0db92 at calltrap+0x8 >> >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e >> >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 >> >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 >> >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 >> >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c >> >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 >> >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 >> >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb >> >> Uptime: 1m51s >> >> >> >> Unfortunately it's ZFS only, so I have no space to white panic dump. >> >> >> >> I'm now trying to rebuild kernel with debugger turned on, as luckily I have >> >> working console@SOL... >> >> >> >> Any preliminary hints? >> >> >> >> >> > >> > -- >> > Sincerely, >> > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] >> > [ FreeBSD committer: marck@FreeBSD.org ] >> > ------------------------------------------------------------------------ >> > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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" >> > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > 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 Tue Nov 18 19:49:28 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DED7A1E5 for ; Tue, 18 Nov 2014 19:49:28 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 902FBA53 for ; Tue, 18 Nov 2014 19:49:28 +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.9/8.14.9) with ESMTP id sAIJnRSu081592; Tue, 18 Nov 2014 14:49:27 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <546BA2C3.2010102@sentex.net> Date: Tue, 18 Nov 2014 14:49:23 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Dmitry Morozovsky , stable@FreeBSD.org Subject: Re: stab;e/10 panic under disk load References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 19:49:29 -0000 On 11/18/2014 11:17 AM, Dmitry Morozovsky wrote: > Dear colleagues, > > my backup server after updrade to frest stable/10 Hi, What kernel were you running prior to the update ? ---Mike -- ------------------- 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 Tue Nov 18 20:05:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E82F621; Tue, 18 Nov 2014 20:05:36 +0000 (UTC) Received: from smtpout7.timeweb.ru (smtpout7.timeweb.ru [92.53.117.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EB13C1D; Tue, 18 Nov 2014 20:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=4oODG3rHltTqBvNcPsaxx94zQ25RIHBgFFKsLIRWeJU=; b=hH8FAEdNPflrUHUPMGeD8fiJZpTsx948zYVdU6PuBNKlFC0NA277k+El1E8f3mAZ5KQ5W6jKBTXC0Hzhph+26x6N72ipWgTScfcLqWQ7lrKC8AXv004g2ESXhcKkCcNMKR7QVndOhpR/iZMEVxpiSVfGnLyDyTisA9s6q+9Pcu0=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xqp1l-000BrU-Sy; Tue, 18 Nov 2014 23:05:29 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 6A651779; Wed, 19 Nov 2014 00:05:29 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 608588E04; Tue, 18 Nov 2014 23:05:29 +0300 (MSK) Date: Tue, 18 Nov 2014 23:05:29 +0300 From: Dmitry Marakasov To: Dimitry Andric Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD Message-ID: <20141118200529.GC62527@hades.panopticon> References: <20140228143606.GD29171@hades.panopticon> <20140228154328.GA13454@hades.panopticon> <20140922231016.GA1301@hades.panopticon> <542105A3.4090507@iki.fi> <98949B82-4109-4628-BE4E-9817D5614D8A@FreeBSD.org> <20140923114447.GB1301@hades.panopticon> <0DFE857D-C33C-49BF-BCCE-16E89DB77AF1@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0DFE857D-C33C-49BF-BCCE-16E89DB77AF1@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-toolchain@freebsd.org, freebsd-stable@FreeBSD.org, Pasi Parviainen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 20:05:36 -0000 * Dimitry Andric (dim@FreeBSD.org) wrote: > >>> This seems to be same issue as in > >>> http://llvm.org/bugs/show_bug.cgi?id=20893 for which there is patch > >>> review going > >>> on http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140922/236415.html. > >>> > >>> Your test case is reproducible with the trunk of llvm/clang and > >>> the patch in review resolves it. Other workaround is to disable > >>> generation of debug information by removing -g flag. > >> > >> Hm, I had assumed this problem was fixed by importing r203311 from > >> upstream llvm trunk, in head r263313. But apparently it is not. > >> > >> The upstream patch seems to fix your specific test case, but it is still > >> in review, so I prefer to wait until it is actually committed, before I > >> import it. > > > > Which worries me is what we do if it's not reviewd until the release. We > > can't just tell users to "remove -g flag", can't we? > > I don't expect the review to take very long, but this is how it goes > with releases. At some point, the release is cut, some bugs don't get > fixed, and you will simply have to live with them. > > In any case, it entirely depends on how many ports it affects. I have > the impression it is just a few particular ports having this issue? The bug seem to have been fixed: http://llvm.org/bugs/show_bug.cgi?id=20893 http://llvm.org/bugs/show_bug.cgi?id=19031 This is unfortunately too late for 10.1, but can we possibly have the fix backported into HEAD and 10-STABLE? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 23:23:13 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B9A02D5; Tue, 18 Nov 2014 23:23:13 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C81702D3; Tue, 18 Nov 2014 23:23:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::609f:bb8:1285:c55d] (unknown [IPv6:2001:7b8:3a7:0:609f:bb8:1285:c55d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4C0B2B80A; Wed, 19 Nov 2014 00:23:08 +0100 (CET) Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_358C5AE6-0D02-41D0-AD0A-4AC148AB351A"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: <20141118200529.GC62527@hades.panopticon> Date: Wed, 19 Nov 2014 00:23:02 +0100 Message-Id: <80988786-733F-4633-ADFB-844FD0DF78EE@FreeBSD.org> References: <20140228143606.GD29171@hades.panopticon> <20140228154328.GA13454@hades.panopticon> <20140922231016.GA1301@hades.panopticon> <542105A3.4090507@iki.fi> <98949B82-4109-4628-BE4E-9817D5614D8A@FreeBSD.org> <20140923114447.GB1301@hades.panopticon> <0DFE857D-C33C-49BF-BCCE-16E89DB77AF1@FreeBSD.org> <20141118200529.GC62527@hades.panopticon> To: Dmitry Marakasov X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 23:23:13 -0000 --Apple-Mail=_358C5AE6-0D02-41D0-AD0A-4AC148AB351A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18 Nov 2014, at 21:05, Dmitry Marakasov wrote: >=20 > * Dimitry Andric (dim@FreeBSD.org) wrote: >=20 >>>>> This seems to be same issue as in >>>>> http://llvm.org/bugs/show_bug.cgi?id=3D20893 for which there is = patch >>>>> review going >>>>> on = http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140922/23641= 5.html. >>>>>=20 >>>>> Your test case is reproducible with the trunk of llvm/clang and >>>>> the patch in review resolves it. Other workaround is to disable >>>>> generation of debug information by removing -g flag. >>>>=20 >>>> Hm, I had assumed this problem was fixed by importing r203311 from >>>> upstream llvm trunk, in head r263313. But apparently it is not. >>>>=20 >>>> The upstream patch seems to fix your specific test case, but it is = still >>>> in review, so I prefer to wait until it is actually committed, = before I >>>> import it. >>>=20 >>> Which worries me is what we do if it's not reviewd until the = release. We >>> can't just tell users to "remove -g flag", can't we? >>=20 >> I don't expect the review to take very long, but this is how it goes >> with releases. At some point, the release is cut, some bugs don't = get >> fixed, and you will simply have to live with them. >>=20 >> In any case, it entirely depends on how many ports it affects. I = have >> the impression it is just a few particular ports having this issue? >=20 > The bug seem to have been fixed: >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D20893 > http://llvm.org/bugs/show_bug.cgi?id=3D19031 >=20 > This is unfortunately too late for 10.1, but can we possibly have the > fix backported into HEAD and 10-STABLE? Yes, I have already imported the fix in r274442; I will probably get the MFC reminder tomorrow. I'm sorry the fix could not make it into 10.1, but apparently the first version of it was not the proper way of solving the problem. The final version took quite a while, unfortunately. -Dimitry --Apple-Mail=_358C5AE6-0D02-41D0-AD0A-4AC148AB351A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRr1NoACgkQsF6jCi4glqPg+gCfYfnA2wiRUyiYpXB6R2adQxwR /7AAoMDJVUPsIjtPz9On+Y2RZLXUbYyl =LKwm -----END PGP SIGNATURE----- --Apple-Mail=_358C5AE6-0D02-41D0-AD0A-4AC148AB351A-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 23:32:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66DF969C for ; Tue, 18 Nov 2014 23:32:22 +0000 (UTC) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27BF13E8 for ; Tue, 18 Nov 2014 23:32:21 +0000 (UTC) Received: from lonrach-2.local (foret.keltia.net [78.232.116.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 02087529E for ; Wed, 19 Nov 2014 00:32:18 +0100 (CET) Date: Wed, 19 Nov 2014 00:32:13 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Subject: Re: best overall upgrade from 8.x? Message-ID: <20141118233212.GA69152@lonrach-2.local> References: <54673CA1.5020008@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54673CA1.5020008@netfence.it> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Nov 2014 23:32:22 -0000 According to Andrea Venturoli: > Uh... is direct upgrade (using sources) possible from 8.4 to 10.1? > No need to step through 9.x? Source upgrade from 8-9 to 10 was broken for one year (bootstrapping issues with flex) but I fixed it some time ago. http://svnweb.freebsd.org/base?view=revision&revision=269967 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 00:17:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB24F1DA; Wed, 19 Nov 2014 00:17:44 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63D7BA0F; Wed, 19 Nov 2014 00:17:44 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAJ0IXGd004569; Tue, 18 Nov 2014 16:18:33 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD ports" , "FreeBSD STABLE" From: "Chris H" Subject: How to recover local.sqlite (pkg(8) problem) Date: Tue, 18 Nov 2014 16:18:33 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <61ee02eda8e8d3c86fadc175453ffb68@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 00:17:44 -0000 Greetings, During the building of a meta-port in the ports tree. My /var/db/pkg/local.sqlite database became corrupted. I spent some time, both with the pkg man pages, and with sqlite3 itself attempting to use one of the backups created by periodic(8). Located in /var/backups. But all to no avail. For the record, I used pkg backup -r /var/backup/pkg.sql.xz, as well as unpacking a copy of that file, and issuing the same. Moving (renaming) the corrupted database aside, prior to. I also issued sqlite3 local.sqlite followed by read pkg.sql and quit went w/o issue. But issuing pkg info emitted several error messages. Which appeared to be from sqlite3(8). This is on RELENG_9, w/source, and kernel world from about 1 week ago. I know that the backup is in good shape, as I had been using it w/o issue. Is this a bug? Thank you for all your time, and consideration. --Chris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 00:21:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 262C2386; Wed, 19 Nov 2014 00:21:32 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5819A3D; Wed, 19 Nov 2014 00:21:31 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id r20so127591wiv.2 for ; Tue, 18 Nov 2014 16:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eHp8wGyVNIetBBao/HN5xT5xavclZKAYZ3BLEPX8Kyg=; b=WC84JxtLETC9sKvKdeMhuFX4h3F/e5K6yiWkcAM++B/BnCCtQl5ZQduXMTVdHkNfcl KCA4TIYVY5jqxMj8/zN6nErFUtQbobLwHWL1l7HUUhe+sgvVoYNDRDWCPJqwoHmxBJzs IZ1NhTl/x4NSwQZ5EQkkm1CaPZ9mvQ6C/W1ShRpnxElLOrTZGaNTBh/5DZInI9yxJPic eZab1H47C6i00UN6EzeLnBR4zKAdrnqVHwFoxEHMesedB7IiYDHuz3eXt/ksdi67lllG YErUkJ3dXDgooAfhnENDrj4Wo4vbRQyeA3FPEXpeRF3/Ckxae0E+W7c78E4m1ODTqesw oSFQ== X-Received: by 10.194.59.17 with SMTP id v17mr7976888wjq.130.1416356490148; Tue, 18 Nov 2014 16:21:30 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id bj7sm43127wjc.33.2014.11.18.16.21.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Nov 2014 16:21:29 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 19 Nov 2014 01:21:27 +0100 From: Baptiste Daroussin To: Chris H Subject: Re: How to recover local.sqlite (pkg(8) problem) Message-ID: <20141119002126.GN48896@ivaldir.etoilebsd.net> References: <61ee02eda8e8d3c86fadc175453ffb68@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5FetH82qe0Z6y/zI" Content-Disposition: inline In-Reply-To: <61ee02eda8e8d3c86fadc175453ffb68@ultimatedns.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD STABLE , FreeBSD ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 00:21:32 -0000 --5FetH82qe0Z6y/zI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2014 at 04:18:33PM -0800, Chris H wrote: > Greetings, > During the building of a meta-port in the ports tree. My > /var/db/pkg/local.sqlite database became corrupted. I > spent some time, both with the pkg man pages, and with > sqlite3 itself attempting to use one of the backups > created by periodic(8). Located in /var/backups. But all > to no avail. For the record, I used > pkg backup -r /var/backup/pkg.sql.xz, as well as unpacking > a copy of that file, and issuing the same. Moving (renaming) > the corrupted database aside, prior to. I also issued > sqlite3 local.sqlite > followed by > read pkg.sql > and > quit > went w/o issue. But issuing > pkg info > emitted several error messages. Which appeared to be from > sqlite3(8). > This is on RELENG_9, w/source, and kernel world from about > 1 week ago. I know that the backup is in good shape, as I > had been using it w/o issue. > Is this a bug? >=20 > Thank you for all your time, and consideration. >=20 This is really surprising and first time this can of things get reported, c= an you provide me the the pkg.sql.xz file? Are you runing on nfs? if yes start the lockd first (pkg should fallback on= a working solution (I need to check for pkg backup) but sqlite3 cli tool does= not and sqlite3 cli tool on nfs without proper locking is known to corrupt data= base file. Best regards, Bapt --5FetH82qe0Z6y/zI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRr4oYACgkQ8kTtMUmk6EyEnACffZfQHllsKs84dCUTt1328xTM TMMAoKf5hPCHC6b1c8BJw8vV5wpZ96Vi =7X7Y -----END PGP SIGNATURE----- --5FetH82qe0Z6y/zI-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 00:26:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9D16582; Wed, 19 Nov 2014 00:26:22 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 340BBAFC; Wed, 19 Nov 2014 00:26:22 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x12so1310287wgg.33 for ; Tue, 18 Nov 2014 16:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4/gRNVUTtJK1b/undXDMXiGbrbzyzw1WqpFXxYcmmY8=; b=qsE0pBnTmpTggbg4qZ1DFNjSE0963+xiJQSHid+86yZ8XZnP2pf8/dFmMCB0tQmfYr 6nKpnaM0bXxeBfsPICqi7f5nNeoWV9rkObfwhbZuhOQ6EUPPqSwmjMDo52nNdtmEmbFS 8tvlOtWp4QFmxw5jTx3v0PWwv51NyyV7t2O8JCE8uM/MXvJLbzPLwKe4o1UxfPsJTBcn DE0JmeRuX9Nyj52cGdYjhMUA0Y4dg8QEYfdrI3z3HP/zd/fKZSOifYoBwfCr9+KQZ/1+ cn7JyIIObJ4SxKUa/zpPJERWcUkqUTz6XF+fDJWtcESqLuWxT26pMBQfUh51ujQ+oCYC LY3g== X-Received: by 10.195.11.6 with SMTP id ee6mr53012992wjd.95.1416356780661; Tue, 18 Nov 2014 16:26:20 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id cz3sm65342wjb.23.2014.11.18.16.26.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Nov 2014 16:26:19 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 19 Nov 2014 01:26:17 +0100 From: Baptiste Daroussin To: Chris H Subject: Re: How to recover local.sqlite (pkg(8) problem) Message-ID: <20141119002617.GO48896@ivaldir.etoilebsd.net> References: <61ee02eda8e8d3c86fadc175453ffb68@ultimatedns.net> <20141119002126.GN48896@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hXth9cGL35Nvpk4x" Content-Disposition: inline In-Reply-To: <20141119002126.GN48896@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD STABLE , FreeBSD ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 00:26:22 -0000 --hXth9cGL35Nvpk4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2014 at 01:21:27AM +0100, Baptiste Daroussin wrote: > On Tue, Nov 18, 2014 at 04:18:33PM -0800, Chris H wrote: > > Greetings, > > During the building of a meta-port in the ports tree. My > > /var/db/pkg/local.sqlite database became corrupted. I > > spent some time, both with the pkg man pages, and with > > sqlite3 itself attempting to use one of the backups > > created by periodic(8). Located in /var/backups. But all > > to no avail. For the record, I used > > pkg backup -r /var/backup/pkg.sql.xz, as well as unpacking > > a copy of that file, and issuing the same. Moving (renaming) > > the corrupted database aside, prior to. I also issued > > sqlite3 local.sqlite > > followed by > > read pkg.sql > > and > > quit > > went w/o issue. But issuing > > pkg info > > emitted several error messages. Which appeared to be from > > sqlite3(8). > > This is on RELENG_9, w/source, and kernel world from about > > 1 week ago. I know that the backup is in good shape, as I > > had been using it w/o issue. > > Is this a bug? > >=20 > > Thank you for all your time, and consideration. > >=20 > This is really surprising and first time this can of things get reported,= can > you provide me the the pkg.sql.xz file? >=20 > Are you runing on nfs? if yes start the lockd first (pkg should fallback = on a > working solution (I need to check for pkg backup) but sqlite3 cli tool do= es not > and sqlite3 cli tool on nfs without proper locking is known to corrupt da= tabase > file. >=20 > Best regards, > Bapt Right checked I forgot to add the lock workaround on pkg backup I'll fix in 1.4.0 in the mean time you just have to start lockd (service lockd start) a= nd the recovery will just work. It might have been corrupted because a background backup (without the proper lock workaround) happened at the same time you were via the ports tree runn= ing the pkg command. Best regards, Bapt --hXth9cGL35Nvpk4x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRr46kACgkQ8kTtMUmk6EzqBQCgpNhn7amV9M3kLCCGW2Gt4Zle 9VwAnjUBZdn5hhxIm06yEgQeThNqXgla =4yjF -----END PGP SIGNATURE----- --hXth9cGL35Nvpk4x-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 00:27:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27AE070A; Wed, 19 Nov 2014 00:27:11 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6BB6B18; Wed, 19 Nov 2014 00:27:10 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAJ0S0fW009197; Tue, 18 Nov 2014 16:28:00 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Baptiste Daroussin In-Reply-To: <20141119002126.GN48896@ivaldir.etoilebsd.net> References: <61ee02eda8e8d3c86fadc175453ffb68@ultimatedns.net>, <20141119002126.GN48896@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: How to recover local.sqlite (pkg(8) problem) Date: Tue, 18 Nov 2014 16:28:00 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <63949c1adf7bfde2935fe0a559ea2bcb@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD STABLE , FreeBSD ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 00:27:11 -0000 On Wed, 19 Nov 2014 01:21:27 +0100 Baptiste Daroussin wrote > On Tue, Nov 18, 2014 at 04:18:33PM -0800, Chris H wrote: > > Greetings, > > During the building of a meta-port in the ports tree. My > > /var/db/pkg/local.sqlite database became corrupted. I > > spent some time, both with the pkg man pages, and with > > sqlite3 itself attempting to use one of the backups > > created by periodic(8). Located in /var/backups. But all > > to no avail. For the record, I used > > pkg backup -r /var/backup/pkg.sql.xz, as well as unpacking > > a copy of that file, and issuing the same. Moving (renaming) > > the corrupted database aside, prior to. I also issued > > sqlite3 local.sqlite > > followed by > > read pkg.sql > > and > > quit > > went w/o issue. But issuing > > pkg info > > emitted several error messages. Which appeared to be from > > sqlite3(8). > > This is on RELENG_9, w/source, and kernel world from about > > 1 week ago. I know that the backup is in good shape, as I > > had been using it w/o issue. > > Is this a bug? > > > > Thank you for all your time, and consideration. > > > This is really surprising and first time this can of things get reported, can > you provide me the the pkg.sql.xz file? > > Are you runing on nfs? if yes start the lockd first (pkg should fallback on a > working solution (I need to check for pkg backup) but sqlite3 cli tool does > not and sqlite3 cli tool on nfs without proper locking is known to corrupt > database file. Thank you for your rapid reply, Baptiste! No. This is UFS2 only -- no nfs, no zfs. I'll send you a copy of the pkg.sql.xz directly. I did notice that when I used the sqlite3 cli, that the database was created, and that the size looked correct. But issuing pkg info resulted in many SQL related errors. Anyway. I'll send you the file. Thanks, again. --Chris > > Best regards, > Bapt From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 00:54:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 099EDE06; Wed, 19 Nov 2014 00:54:50 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD4C9DB6; Wed, 19 Nov 2014 00:54:49 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id r2so109923igi.12 for ; Tue, 18 Nov 2014 16:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/bjgFbIJ62oloQS9nRXmIqKBpfle9/1oQ5jL8+sOc34=; b=sJ/6LjM36c2k9eybmHt00GCD3Lk6YpEg8na4ZEubIk1x5JYQyJP1+aKz07p6cPNpqZ iTShI0wnsIabCzZIX7t9gAriIef4sD+BgsJqoxVXOrVdYLqXAb9iHhiphgdne8Wm6dkl XyEpINnNR3Qc9RbE07pdoq9C8GSldelBWruUvGutsMWoxfbwsDLbZ+amKMYtNf2OzQf3 ks5FUb62z9G7oVA58k/AEqyEkRgnfvPwsnlgBg8Lf1RMpuXL08Ql568B0FnQn8eOiRlW cRQXNIvvFzd35un+bETvw4E4b7z45IZfX7M6qRenfv4TLHKKTWUXgEnhYzDp3hDcJZxW aIDA== MIME-Version: 1.0 X-Received: by 10.43.172.6 with SMTP id nw6mr156850icc.89.1416358489153; Tue, 18 Nov 2014 16:54:49 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.7.169 with HTTP; Tue, 18 Nov 2014 16:54:49 -0800 (PST) In-Reply-To: <80988786-733F-4633-ADFB-844FD0DF78EE@FreeBSD.org> References: <20140228143606.GD29171@hades.panopticon> <20140228154328.GA13454@hades.panopticon> <20140922231016.GA1301@hades.panopticon> <542105A3.4090507@iki.fi> <98949B82-4109-4628-BE4E-9817D5614D8A@FreeBSD.org> <20140923114447.GB1301@hades.panopticon> <0DFE857D-C33C-49BF-BCCE-16E89DB77AF1@FreeBSD.org> <20141118200529.GC62527@hades.panopticon> <80988786-733F-4633-ADFB-844FD0DF78EE@FreeBSD.org> Date: Tue, 18 Nov 2014 16:54:49 -0800 X-Google-Sender-Auth: zYI_ryhhljpk4UBTMw63BXhDPIU Message-ID: Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD From: Kevin Oberman To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Dmitry Marakasov , FreeBSD-STABLE Mailing List , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 00:54:50 -0000 On Tue, Nov 18, 2014 at 3:23 PM, Dimitry Andric wrote: > On 18 Nov 2014, at 21:05, Dmitry Marakasov wrote: > > > > * Dimitry Andric (dim@FreeBSD.org) wrote: > > > >>>>> This seems to be same issue as in > >>>>> http://llvm.org/bugs/show_bug.cgi?id=20893 for which there is patch > >>>>> review going > >>>>> on > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140922/236415.html > . > >>>>> > >>>>> Your test case is reproducible with the trunk of llvm/clang and > >>>>> the patch in review resolves it. Other workaround is to disable > >>>>> generation of debug information by removing -g flag. > >>>> > >>>> Hm, I had assumed this problem was fixed by importing r203311 from > >>>> upstream llvm trunk, in head r263313. But apparently it is not. > >>>> > >>>> The upstream patch seems to fix your specific test case, but it is > still > >>>> in review, so I prefer to wait until it is actually committed, before > I > >>>> import it. > >>> > >>> Which worries me is what we do if it's not reviewd until the release. > We > >>> can't just tell users to "remove -g flag", can't we? > >> > >> I don't expect the review to take very long, but this is how it goes > >> with releases. At some point, the release is cut, some bugs don't get > >> fixed, and you will simply have to live with them. > >> > >> In any case, it entirely depends on how many ports it affects. I have > >> the impression it is just a few particular ports having this issue? > > > > The bug seem to have been fixed: > > > > http://llvm.org/bugs/show_bug.cgi?id=20893 > > http://llvm.org/bugs/show_bug.cgi?id=19031 > > > > This is unfortunately too late for 10.1, but can we possibly have the > > fix backported into HEAD and 10-STABLE? > > Yes, I have already imported the fix in r274442; I will probably get > the MFC reminder tomorrow. > > I'm sorry the fix could not make it into 10.1, but apparently the first > version of it was not the proper way of solving the problem. The final > version took quite a while, unfortunately. > > -Dimitry > > This seems to me like something that deserves an errata note. At the least, it will greatly deduce the number error reports to this list and the bug reports to bugzilla. (Well, maybe not, but I can hope.) -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 04:24:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AFCEA40 for ; Wed, 19 Nov 2014 04:24:40 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBFB56D9 for ; Wed, 19 Nov 2014 04:24:39 +0000 (UTC) Received: (qmail 15350 invoked from network); 19 Nov 2014 04:17:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Nov 2014 04:17:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 18 Nov 2014 23:17:58 -0500 (EST) Received: (qmail 25936 invoked from network); 19 Nov 2014 04:17:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Nov 2014 04:17:58 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id AA20F1C43A3 for ; Tue, 18 Nov 2014 20:17:51 -0800 (PST) From: Mark Millard Subject: FYI: https://www.freebsd.org/releases/10.1R/installation.html says: "For SVN use the releng/10.0 branch" [not releng/10.1] Message-Id: <6FA29C0B-BDDA-4185-97FC-D564D130A470@dsl-only.net> Date: Tue, 18 Nov 2014 20:17:56 -0800 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 04:24:40 -0000 https://www.freebsd.org/releases/10.1R/installation.html says: > For SVN use the releng/10.0 branch which will be where any upcoming = Security Advisories or Errata Notices will be applied. Note the "10.0" instead of "10.1". I looked and http://svnweb.freebsd.org/base/releng/10.1/ does exist so = it would appear that it is at least being prepared. Do I misunderstand = the intent? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 04:38:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02916E9D; Wed, 19 Nov 2014 04:38:43 +0000 (UTC) Date: Wed, 19 Nov 2014 04:38:40 +0000 From: Glen Barber To: Mark Millard Subject: Re: FYI: https://www.freebsd.org/releases/10.1R/installation.html says: "For SVN use the releng/10.0 branch" [not releng/10.1] Message-ID: <20141119043840.GB27149@hub.FreeBSD.org> References: <6FA29C0B-BDDA-4185-97FC-D564D130A470@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <6FA29C0B-BDDA-4185-97FC-D564D130A470@dsl-only.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 04:38:44 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2014 at 08:17:56PM -0800, Mark Millard wrote: > https://www.freebsd.org/releases/10.1R/installation.html says: >=20 > > For SVN use the releng/10.0 branch which will be where any upcoming Sec= urity Advisories or Errata Notices will be applied. >=20 > Note the "10.0" instead of "10.1". >=20 Fixed in r46001 of the documentation tree, and the change should be live within the next few minutes. Thank you for the report. Glen --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUbB7QAAoJEAMUWKVHj+KTkd4P/iSuWD7/huKauJpFfNGifR9B xj0iKtpFnaRPk1JPCYz2CaNUbh5/uHA201LGRsaG/PNe1lOwTRNsOteFzWdtYUMw evxZZzs3zTXoJOU++/vybHhO4EY10xYnY808S/icovqHTzhoavtuinxaYK6XodO0 uUX+N+JwJUsOihLiG2KfXf8zi1K5F3le/o11jd63DNwPkt2AV/EpLvY93jlqfrSh cekaTm/xMaQf8da3RpIfj7fTPVlnC+H8lLUVzCTdwONTg3aV23VL17q64TssS/sK y4sAI/4vSioQws7vDEd+v/orQZnVDj44CFtOQ9uYwW/X/8SRe3Fg1lUd/ritAiMk BmnETDmf2w9SfyvxTQkWcn7xoc5i/UOXmHRUJBPg9smkLt0MCNL6Gr/ZFh2TrYmJ UvxWv4GTy4cWZceweib1/pdimggVZUBJ2p721Hnzcm6e71vrkYZH/nxJlhRsdgMQ lPJ4xn9cL5ODsrDCPOnqHyb/g/5vtMIN/epGys23oAk9soznHZ6wBCbvvTCkNxRz mAWczRmuWYSM88WaRQzSP2fWDnQIAO54Pf7BGq1+dATedNfO0LCOVlY/cf+IGKZz qLo1U2ZaQmbrofCGKJuQ5Ao1yaKtMk4CcECBoHkSCx7aTUu/yLVHzmwl0wtkCL2F anjOtNp0Wq3Pf6AtmyAQ =mEd7 -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 08:04:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A8CE622; Wed, 19 Nov 2014 08:04:40 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FC18EB5; Wed, 19 Nov 2014 08:04:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::609f:bb8:1285:c55d] (unknown [IPv6:2001:7b8:3a7:0:609f:bb8:1285:c55d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 90680B80A; Wed, 19 Nov 2014 09:04:29 +0100 (CET) Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6F32AAE7-F738-4773-9FBF-D9457B2250B0"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b1 From: Dimitry Andric In-Reply-To: Date: Wed, 19 Nov 2014 09:04:20 +0100 Message-Id: <66FD0611-16EE-4AA8-AD7D-479E63A1DCC3@FreeBSD.org> References: <20140228143606.GD29171@hades.panopticon> <20140228154328.GA13454@hades.panopticon> <20140922231016.GA1301@hades.panopticon> <542105A3.4090507@iki.fi> <98949B82-4109-4628-BE4E-9817D5614D8A@FreeBSD.org> <20140923114447.GB1301@hades.panopticon> <0DFE857D-C33C-49BF-BCCE-16E89DB77AF1@FreeBSD.org> <20141118200529.GC62527@hades.panopticon> <80988786-733F-4633-ADFB-844FD0DF78EE@FreeBSD.org> To: Kevin Oberman X-Mailer: Apple Mail (2.1993) Cc: freebsd-toolchain@freebsd.org, FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 08:04:40 -0000 --Apple-Mail=_6F32AAE7-F738-4773-9FBF-D9457B2250B0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 19 Nov 2014, at 01:54, Kevin Oberman wrote: > > On Tue, Nov 18, 2014 at 3:23 PM, Dimitry Andric wrote: ... >> Yes, I have already imported the fix in r274442; I will probably get >> the MFC reminder tomorrow. >> >> I'm sorry the fix could not make it into 10.1, but apparently the first >> version of it was not the proper way of solving the problem. The final >> version took quite a while, unfortunately. .. > This seems to me like something that deserves an errata note. At the > least, it will greatly deduce the number error reports to this list and the > bug reports to bugzilla. (Well, maybe not, but I can hope.) As far as I know, Errata Notes are only issued for security issues (and probably only severe ones, without a workaround). -Dimitry --Apple-Mail=_6F32AAE7-F738-4773-9FBF-D9457B2250B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlRsTwwACgkQsF6jCi4glqPVHwCdHmSrgb0q+3SlMRey0upLfYb/ 5SgAn06sCdg4SNLU8xGi7fipWY1bojzX =nYat -----END PGP SIGNATURE----- --Apple-Mail=_6F32AAE7-F738-4773-9FBF-D9457B2250B0-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 08:31:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 327F992A; Wed, 19 Nov 2014 08:31:54 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F10A11AC; Wed, 19 Nov 2014 08:31:53 +0000 (UTC) Received: from [192.168.0.106] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.9/8.14.9) with ESMTP id sAJ8VmPA026677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Nov 2014 08:31:50 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52] claimed to be [192.168.0.106] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD From: David Chisnall In-Reply-To: <66FD0611-16EE-4AA8-AD7D-479E63A1DCC3@FreeBSD.org> Date: Wed, 19 Nov 2014 08:31:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6C4E3AA9-5092-42DA-8BE7-4F303F0CA8ED@FreeBSD.org> References: <20140228143606.GD29171@hades.panopticon> <20140228154328.GA13454@hades.panopticon> <20140922231016.GA1301@hades.panopticon> <542105A3.4090507@iki.fi> <98949B82-4109-4628-BE4E-9817D5614D8A@FreeBSD.org> <20140923114447.GB1301@hades.panopticon> <0DFE857D-C33C-49BF-BCCE-16E89DB77AF1@FreeBSD.org> <20141118200529.GC62527@hades.panopticon> <80988786-733F-4633-ADFB-844FD0DF78EE@FreeBSD.org> <66FD0611-16EE-4AA8-AD7D-479E63A1DCC3@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1878.6) Cc: Kevin Oberman , freebsd-toolchain@freebsd.org, FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 08:31:54 -0000 On 19 Nov 2014, at 08:04, Dimitry Andric wrote: > As far as I know, Errata Notes are only issued for security issues = (and > probably only severe ones, without a workaround). Security Advisories are for security issues. Errata Notes are for... = errata. The confusion comes from the fact that ENs go via freebsd-update, which = is managed by secteam, so using them for anything is a bit harder than = it should be (should be fixed in 11). This seems like a fairly good = candidate though. David From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 09:42:31 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AF87281 for ; Wed, 19 Nov 2014 09:42:31 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F394AB16 for ; Wed, 19 Nov 2014 09:42:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAJ9g54V017738; Wed, 19 Nov 2014 12:42:05 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 19 Nov 2014 12:42:05 +0300 (MSK) From: Dmitry Morozovsky To: Mike Tancsa Subject: Re: stab;e/10 panic under disk load In-Reply-To: <546BA2C3.2010102@sentex.net> Message-ID: References: <546BA2C3.2010102@sentex.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 19 Nov 2014 12:42:05 +0300 (MSK) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 09:42:31 -0000 On Tue, 18 Nov 2014, Mike Tancsa wrote: > > my backup server after updrade to frest stable/10 > > Hi, > What kernel were you running prior to the update ? stable/10 at somewhere within 10.1-PRE -- but in the past there were not much activity with restoring many files and mixing them with rsync at once, so the bug could lay much deeper in time -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 09:43:41 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E07B339D; Wed, 19 Nov 2014 09:43:41 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62559B3F; Wed, 19 Nov 2014 09:43:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAJ9dB9S017713; Wed, 19 Nov 2014 12:40:11 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 19 Nov 2014 12:39:11 +0300 (MSK) From: Dmitry Morozovsky To: "K. Macy" Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] In-Reply-To: Message-ID: References: <-7425247475772590723@unknownmsgid> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 19 Nov 2014 12:40:11 +0300 (MSK) Cc: "stable@freebsd.org" , Steven Hartland , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 09:43:42 -0000 On Tue, 18 Nov 2014, K. Macy wrote: > >> Can u plug a usb drive in to get a dump? > > > > Hm, will it work over USB stack? I can try this. > > > > BTW: it seems some internal ZFS locking trouble exists, as trere are 3 cases: > > > > pool/R/fs1 mounted as /fs1 > > pool/R/fs2 > > pool/R/fs3 > > > > tar cf - /fs1 >/dev/null works ok > > tar cf - /fs2 >/dev/null works ok > > rsync -avHP /fs1/ /fs2/ panics in few minutes > > > > will try to configure dump to USB SATA > > > > Are you using extended attributes at all? As far as I can tell, no -- unless they are created by restore(8). [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 10:38:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C053250 for ; Wed, 19 Nov 2014 10:38:09 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B324812E for ; Wed, 19 Nov 2014 10:38:08 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id u10so240008lbd.31 for ; Wed, 19 Nov 2014 02:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GHAEqsa9O9d72mgFScjtTha99rXTodhRlH51HYFoLkE=; b=RmgsK/slEhRQRCIiQOo3S/3JEmN8mZQSzzWHP8J5Xd0l/55y86AxdP/WJx9zIqpcv0 fUjtmEI2su2GXDIRJtT7hEEByQFGgNp+eLCv5DLtonp3DhVVA0WMLLnvZwi2ckaza2Ij Mk/zpC5WzXD8gzZwwxK2b2T8+5aF3gdpIRqb0Me1E0OcZJ7kkA1XQqIRepqaH4CUKsmQ jbtk9+z5ITbcQB1QeBYpOHIRBjy1/qQQNTtvpQqZ54/MvLlhtnU20KoJb+YDaqTIg1W2 02LGPBK1CYmZIhblM0x91o4yXpZZoPfNsYHBjfmpLFDta9iuQ0PyRkd3ZLZplvd8DO+u w/wA== X-Received: by 10.152.87.100 with SMTP id w4mr4600444laz.27.1416393486686; Wed, 19 Nov 2014 02:38:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.90.201 with HTTP; Wed, 19 Nov 2014 02:37:36 -0800 (PST) In-Reply-To: <546B27C6.10403@gmail.com> References: <546B27C6.10403@gmail.com> From: Matthias Gamsjager Date: Wed, 19 Nov 2014 11:37:36 +0100 Message-ID: Subject: Re: Native ISCSI FreeBSD 10 stable To: Johan Hendriks Content-Type: text/plain; charset=UTF-8 Cc: stable-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 10:38:09 -0000 Could you post the config files? I have to say I don't see any performance difference with the kernel iscsi impl. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 14:21:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B44FB442 for ; Wed, 19 Nov 2014 14:21:01 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B8C2D90 for ; Wed, 19 Nov 2014 14:21:00 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id sAJE7h34068851 for ; Wed, 19 Nov 2014 15:07:43 +0100 (CET) Received: from hausen-mbp-5.intern.punkt.de (hausen-mbp-5.intern.punkt.de [217.29.45.148]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id sAJE7hnd076919 for ; Wed, 19 Nov 2014 15:07:43 +0100 (CET) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: 10.1 fresh install and 4k alignment Message-Id: Date: Wed, 19 Nov 2014 15:07:43 +0100 To: "freebsd-stable@freebsd.org List" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 14:21:01 -0000 Hi, all, I just installed a new machine with 10.1-RELEASE using the memstick = installer and chosing ZFS mirror root as the disk layout. I did check the "4k" option, watched the installer do the necessary gnop = dance and the pool seems to be OK: root@seleniumhub:~ # zdb | grep ashift ashift: 12 But this puzzles me a bit: root@seleniumhub:~ # gpart list ada0 Mediasize: 524288 (512K) Sectorsize: 512 ... Providers: 1. Name: ada0p1 Mediasize: 524288 (512K) Sectorsize: 512 ... end: 1057 start: 34 ... 3. Name: ada0p3 Mediasize: 465747565056 (434G) Sectorsize: 512 ... type: freebsd-zfs ... end: 976773134 start: 67109922 None of the start sector numbers is a multiple of 8, neither are the end = sectors a multiple of 8 minus 1. So the pool uses a 4k block size but it starts on an odd multiple of 2k = on the platter - do I see this correctly? Isn't it absolutely necessary that the simulated 4k blocks are laid out = so that the first is made from 512 byte sectors 0-7, the second from 8-15 and so on? Then why does the installer start the first partition at 512 byte sector = 34? While I'm at it, this magic number is everywhere in the older documentation, e.g. for = manually installing FreeBSD 8 with gptzfsboot - where does that 34 come from? = It's not a power of 2 nor is it one of the historical CHS magic numbers that = would mean a cylinder boundary or similar. Size of the GPT partition table itself? Is this a bug in the installer? Will I still have to layout the disks = manually if I want 4k alignment? What's a good offset for the first partition in this case? = Anything bigger than 34 that's a multiple of 8 - 40 or 64? Thanks in advance Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 14:28:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34BE384E; Wed, 19 Nov 2014 14:28:21 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9204EDFC; Wed, 19 Nov 2014 14:28:20 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id u10so588543lbd.3 for ; Wed, 19 Nov 2014 06:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qReL0l4gHo/jVvxHSRd5xIzW+NaZUISOOcXsNn3LidQ=; b=pCI0LQboemTAGv+OlHRtBTo5uPwBJVh/zrI9jcXes11xlh23qFK4O3Y/dslt5mL11N iDhCswEGK0///pFu+WaPisAs/mxKiOz2T7q+lJAgphEklEEoltnAvugR01skM+nIVxlB My9elASDEaUrXy4k2HAioTuDf181AvYOBSYc8ytYtLkyEGUglBAAoHeeKyWnZWSuj+ON 2FIjiv8MKIIIOCWnv3JFpRttCHCsXyFYhra+BgutYL+Cq7miqoBKmf5N54ccuDXAFA5O zhh2i6t/VfQbtAGwMVtWHmeodm5UmjqwLtqgUjv9dejSxW3ZmbazU6rIMFdPcwcrFPao nthA== MIME-Version: 1.0 X-Received: by 10.112.133.138 with SMTP id pc10mr5729236lbb.48.1416407298315; Wed, 19 Nov 2014 06:28:18 -0800 (PST) Received: by 10.25.170.66 with HTTP; Wed, 19 Nov 2014 06:28:18 -0800 (PST) In-Reply-To: References: <3C955A8F-9D1A-463B-BB9A-256C36BF0D4C@gromit.dlib.vt.edu> Date: Wed, 19 Nov 2014 15:28:18 +0100 Message-ID: Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles From: Andreas Nilsson To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Daniel O'Connor , FreeBSD Stable Mailing List , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 14:28:21 -0000 On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky wrote: > Daniel, > > nice to see you here too ;) > > On Fri, 14 Nov 2014, Daniel O'Connor wrote: > > > > > On 12 Nov 2014, at 19:43, Andreas Nilsson wrote: > > > unclear is the word for it :) And thanks for looking into this. > ipmi/ilo is > > > important on a server os. > > > > > > I found a reference to it in a ML post: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.html > > > > I started that thread :) > > I did get it working on the hardware I was using (Supermicro X9SCL-F and > X8SIL-F) > > > > I used the following BIOS settings > > ? Remote Access - Enabled > > ? Serial Port Number - COM3 > > ? Serial Port Mode - 115200, 8, n, 1 > > ? Flow Control - Hardware > > ? Redirection After BIOS POST - Always > > ? Terminal Type - VT100 > > ? VT-UTF8 Combo Key Support - Disabled > > ? Sredir Memory Display Delay - No Delay > > > > And the following in loader.conf > > # Give preference to VGA console > > console="vidconsole,comconsole" > > # Uncomment below and comment above to give serial console preference > > #console="comconsole,vidconsole" > > comconsole_speed="115200" > > boot_multicons="YES" > > hint.uart.0.flags="0x0" > > hint.uart.2.at="isa" > > hint.uart.2.port="0x3E8" > > hint.uart.2.flags="0x30" > > > > And this in /etc/ttys > > # IPMI console > > # Note: The Java console viewer doesn't seem to be very smart as it > doesn't > > # properly support VT100 > > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on secure > > > > I could then access it using ipmitool like so > > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > [login] > > export TERM=xterm > > > > Note that I wanted vidconsole by default because mostly the systems were > used by people local to them, however we could break into the loader and > type 'set console=comconsole,vidconsole? and then get everything over the > serial console for remote trouble shooting. > > > > You may also wish to check the IPMI configuration via the web interface > - by default it will failover to port 0 and it has terrible default > passwords. I changed the passwords and forced it to use the dedicated IPMI > port even if nothing was connected to it. > > Well, I'm almost done with most of our SM server, even concentrated > console on > our console server with such a simple config: > > ---- 8< ---- > # ipmi/sol console template > default ipmi { > master localhost; > type exec; > exec /usr/local/bin/ipmitool -f /usr/local/etc/ipmi-pass -U > root -I lanplus -H %.int sol activate; > execsubst %=cs; > #idletimeout 6h; > > break 0 { string "~B"; } > } > > console gwn1 { include ipmi; } > console gwn2 { include ipmi; } > console gwn3 { include ipmi; } > console gwn4 { include ipmi; } > console gwn5 { include ipmi; } > console gwn6 { include ipmi; } > console gwn7 { include ipmi; } > console gwn8 { include ipmi; } > > console gwc2 { include ipmi; } > ---- 8< ---- > > This has console logging (including possible panics) as a surplus > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > Hello again, Searching on hw.uart.console, I found: http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html , a very enlightening thread. Basically: "ohh, you want to use something other than COM1 and tried to get away with just changing hint.uart stuff, which has worked for a while, ha, no way..." No heads up, nothing. Sorry to say jhb@ but is not a rare case. It is if not the default, a very common setup on every HP server with iLO, and it holds for most all OOB style serial emulation I have ever had the (dis)pleasure of working with. Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 14:32:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 030C9C5E for ; Wed, 19 Nov 2014 14:32:19 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 830DDEDD for ; Wed, 19 Nov 2014 14:32:18 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jjRLR21wCz1Vr for ; Wed, 19 Nov 2014 15:32:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1416407531; x=1418999532; bh=I0G RhR4Pxwk0XtyeLyU7GU+fOvP29UDK10aacfKpKAc=; b=byTqEQaf2rglaePXHkl M4YA7Y4XSyW3nWF/HXZ2qJK+tyEWq97rnvh7ux5P87r/r7j1h2VCYjmuv+fbmjUG VgQ6LctMHrOtPKqDf9sbhGQGxaU7EvksBCUnsUQWI9xnwL5FKciZIcIwc5Elxx33 O/4MaHxLO1moWZZol3XTflXk= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id dlTDbXOJ7FdY for ; Wed, 19 Nov 2014 15:32:11 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 19 Nov 2014 15:32:11 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jjRLM3fQXz1Y7 for ; Wed, 19 Nov 2014 15:32:11 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 19 Nov 2014 15:32:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2014 15:32:11 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org Subject: Re: 10.1 fresh install and 4k alignment Organization: J. Stefan Institute In-Reply-To: References: Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 14:32:19 -0000 Patrick M. Hausen wrote: > Hi, all, > > I just installed a new machine with 10.1-RELEASE using the memstick > installer > and chosing ZFS mirror root as the disk layout. > > I did check the "4k" option, watched the installer do the necessary > gnop dance > and the pool seems to be OK: > > root@seleniumhub:~ # zdb | grep ashift > ashift: 12 > > But this puzzles me a bit: > > root@seleniumhub:~ # gpart list ada0 > Mediasize: 524288 (512K) > Sectorsize: 512 > ... > Providers: > 1. Name: ada0p1 > Mediasize: 524288 (512K) > Sectorsize: 512 > ... > end: 1057 > start: 34 > ... > 3. Name: ada0p3 > Mediasize: 465747565056 (434G) > Sectorsize: 512 > ... > type: freebsd-zfs > ... > end: 976773134 > start: 67109922 > > None of the start sector numbers is a multiple of 8, neither are the > end sectors > a multiple of 8 minus 1. > > So the pool uses a 4k block size but it starts on an odd multiple of > 2k on the platter > - do I see this correctly? > > Isn't it absolutely necessary that the simulated 4k blocks are laid > out so that the first > is made from 512 byte sectors 0-7, the second from 8-15 and so on? > > Then why does the installer start the first partition at 512 byte > sector 34? While I'm at > it, this magic number is everywhere in the older documentation, e.g. > for manually > installing FreeBSD 8 with gptzfsboot - where does that 34 come from? > It's not > a power of 2 nor is it one of the historical CHS magic numbers that > would mean > a cylinder boundary or similar. Size of the GPT partition table itself? > > Is this a bug in the installer? Will I still have to layout the disks > manually if I want 4k > alignment? What's a good offset for the first partition in this case? > Anything bigger > than 34 that's a multiple of 8 - 40 or 64? > > Thanks in advance > Patrick Reported on 2014-10-10, but was apparently forgotten/ignored: "GPT partitions not 4k aligned by 10.1-RC1 installer" https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080509.html Mark From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 14:36:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E93B3F4B for ; Wed, 19 Nov 2014 14:36:25 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CBCFF11 for ; Wed, 19 Nov 2014 14:36:25 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id sAJEaN7d069159; Wed, 19 Nov 2014 15:36:23 +0100 (CET) Received: from hausen-mbp-5.intern.punkt.de (hausen-mbp-5.intern.punkt.de [217.29.45.148]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id sAJEaNpq077810; Wed, 19 Nov 2014 15:36:23 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: 10.1 fresh install and 4k alignment From: "Patrick M. Hausen" In-Reply-To: Date: Wed, 19 Nov 2014 15:36:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Martinec X-Mailer: Apple Mail (2.1993) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 14:36:26 -0000 Hi! > Am 19.11.2014 um 15:32 schrieb Mark Martinec = : > Reported on 2014-10-10, but was apparently forgotten/ignored: >=20 > "GPT partitions not 4k aligned by 10.1-RC1 installer" > = https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080509.htm= l Thanks! I'll try to get away without reinstalling by repartitioning one = drive at a time and sacrificing some swap space if necessary to keep the vdev's = size. Kind regards Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 14:50:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C452983B for ; Wed, 19 Nov 2014 14:50:51 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74360B0 for ; Wed, 19 Nov 2014 14:50:51 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jjRls4St2z7S for ; Wed, 19 Nov 2014 15:50:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1416408646; x=1419000647; bh=WNm 1ES5MEB7bR/vjuFQHSMR5s6wmEDeSuuXJKR3P62k=; b=PyxGEqzisbNIMzNVuzY VxtYy7op/fkrtiD1SsdGE1+h6iDgBADuitPkupFry9Gnn/vZMwq8kBQP4sSHca8C dV7TPUcIuhSfj7L06ty4iruY2SxvCCcdqOBEgkTiF2tBhz9zCVVEz6scSVgDiNjw hX6lPPCJzVWRO4KCTdudBBtA= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id rbCClqf7tzo3 for ; Wed, 19 Nov 2014 15:50:46 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 19 Nov 2014 15:50:46 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jjRlp1lPKz9p for ; Wed, 19 Nov 2014 15:50:46 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 19 Nov 2014 15:50:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2014 15:50:46 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org Subject: Re: 10.1 fresh install and 4k alignment Organization: J. Stefan Institute In-Reply-To: References: Message-ID: <27d8222a2b617ac515c38a0023151320@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 14:50:51 -0000 > None of the start sector numbers is a multiple of 8, neither are the > end sectors a multiple of 8 minus 1. > > So the pool uses a 4k block size but it starts on an odd multiple of 2k > on the platter - do I see this correctly? > [...] > Is this a bug in the installer? Will I still have to layout the disks > manually if I want 4k alignment? What's a good offset for the first > partition in this case? Anything bigger than 34 that's a multiple of > 8 - 40 or 64? >> "GPT partitions not 4k aligned by 10.1-RC1 installer" >> >> https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080509.html I consider a sensible alignment nowadays to be '-a 1m' for any GPT partition, including freebsd-boot. If one is very short on space and not on an SSD, one may save 0.5 MB by aligning freebsd-boot on -a 512k and everything else on '-a 1m': gpart add -t freebsd-boot -a 1m -s 512k -i 1 ... gpart add -t freebsd-swap -a 1m -i 2 ... ... or: gpart add -t freebsd-boot -a 512k -s 512k -i 1 ... gpart add -t freebsd-swap -a 1m -i 2 ... ... Mark From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 14:53:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 471ECAB1 for ; Wed, 19 Nov 2014 14:53:51 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3FA316A for ; Wed, 19 Nov 2014 14:53:50 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id sAJErmXN069378; Wed, 19 Nov 2014 15:53:48 +0100 (CET) Received: from hausen-mbp-5.intern.punkt.de (hausen-mbp-5.intern.punkt.de [217.29.45.148]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id sAJErmMG078367; Wed, 19 Nov 2014 15:53:48 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: 10.1 fresh install and 4k alignment From: "Patrick M. Hausen" In-Reply-To: <27d8222a2b617ac515c38a0023151320@mailbox.ijs.si> Date: Wed, 19 Nov 2014 15:53:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D6C7C39-C8F6-4F5B-AF09-F26B27FA2ED0@punkt.de> References: <27d8222a2b617ac515c38a0023151320@mailbox.ijs.si> To: Mark Martinec X-Mailer: Apple Mail (2.1993) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 14:53:51 -0000 Hi, Mark, > Am 19.11.2014 um 15:50 schrieb Mark Martinec = : >=20 > I consider a sensible alignment nowadays to be '-a 1m' for any > GPT partition, including freebsd-boot. If one is very short on space > and not on an SSD, one may save 0.5 MB by aligning freebsd-boot =20 > on -a 512k and everything else on '-a 1m': > ... Why the "not on an SSD" condition? Thanks Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 15:07:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 660DFE95 for ; Wed, 19 Nov 2014 15:07:06 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 138142D8 for ; Wed, 19 Nov 2014 15:07:06 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jjS6b4PrjzJl for ; Wed, 19 Nov 2014 16:07:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1416409613; x=1419001614; bh=ng/ Xt7YyLKLvyIkCje1w+R2GkpMbTFiEIgqz6Cl6u1s=; b=F/jjyL++dwnMiK7B3JF Aq965GV7kcAq8hE/P+5hkV4VlwFtALQOXQKjbuWATThFh0Niu9JqKNxeoeo6X+k7 BQlMqfX2AAWc6yDBDBUYsdGRJ1lQDTS5WgPMbS67gFZNBeo9mfWqIffs+ciwq/o6 ab36Lq1jygVnwyQgFnXuU7+Y= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 9tvg98eWy8EB for ; Wed, 19 Nov 2014 16:06:53 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 19 Nov 2014 16:06:51 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jjS6M6qfrzL4 for ; Wed, 19 Nov 2014 16:06:51 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 19 Nov 2014 16:06:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2014 16:06:51 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org Subject: Re: 10.1 fresh install and 4k alignment Organization: J. Stefan Institute In-Reply-To: <1D6C7C39-C8F6-4F5B-AF09-F26B27FA2ED0@punkt.de> References: <27d8222a2b617ac515c38a0023151320@mailbox.ijs.si> <1D6C7C39-C8F6-4F5B-AF09-F26B27FA2ED0@punkt.de> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 15:07:06 -0000 >> Am 19.11.2014 um 15:50 schrieb Mark Martinec >> : >> >> I consider a sensible alignment nowadays to be '-a 1m' for any >> GPT partition, including freebsd-boot. If one is very short on space >> and not on an SSD, one may save 0.5 MB by aligning freebsd-boot >> on -a 512k and everything else on '-a 1m': Patrick M. Hausen wrote: > Why the "not on an SSD" condition? Because an SSD erase block is typically 1 MB in size, and it's not desirable to let it shuffle around blocks holding a boot partition when managing some unrelated space that happens to be in the same 1 MB region. Mark Btw: "The Windows Disk Manager in Windows Vista and Windows 7 utilizes a new 1 MB partition alignment scheme" [1] [1] http://en.wikipedia.org/wiki/Disk_partitioning#DOS.2C_Windows.2C_and_OS.2F2 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 15:40:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F85AD12 for ; Wed, 19 Nov 2014 15:40:32 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFA63917 for ; Wed, 19 Nov 2014 15:40:31 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id sAJFeT6Q070521 for ; Wed, 19 Nov 2014 16:40:29 +0100 (CET) Received: from hausen-mbp-5.intern.punkt.de (hausen-mbp-5.intern.punkt.de [217.29.45.148]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id sAJFeT2a080667 for ; Wed, 19 Nov 2014 16:40:29 +0100 (CET) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: 10.1 geom "diskid" Message-Id: Date: Wed, 19 Nov 2014 16:40:29 +0100 To: "freebsd-stable@freebsd.org List" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 15:40:32 -0000 Hi, all, next question, sorry. I just created a fresh 10.1 installation with ZFS. With the last reboot after adding dedicated SSD based l2arc and zil, the underlying devices are referred to by "diskid" instead of the GPT labels I have first been using: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 logs diskid/DISK-BTTV334403R7200GGNp2 ONLINE 0 0 0 cache diskid/DISK-BTTV334403R7200GGNp1 ONLINE 0 0 0 I can live with that, but I do not understand why the ada2 device changed from gpt/* to diskid/* while the others did not? /dev/gpt entries are not even present for ada2, neither are ada2p? At least the system could try to be consistent ;-) Thanks Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 15:44:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73F11EC9; Wed, 19 Nov 2014 15:44:37 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6CA4961; Wed, 19 Nov 2014 15:44:36 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so699919lbv.38 for ; Wed, 19 Nov 2014 07:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Hdj3mVVGWIb/q9fiwL9rqRLASsyEjqqxHED6pAFX3Sc=; b=jssc+SuwhbG+iPm/BYAmgNUgtIM5IgYceALtddzjUdRX+YP3k9gUEwrfcqK9lidMX9 3p62k7QFhJFISl0/TVfwVgl2N7eeMAcCi62D4KMLM3OtQ9lb5d7KjkbVYfq+1FIzNX4j /AmRkVNwYmde6Kmcx5cGcPvHdmIeadwWiZ+E1D6Sl3o4yLKN9I5OiZiCd1E8e9yYebRF yteB8/mqK39frMCgC51ZIiGP/NZAygIJ9xKov7YiSmLRamrO7y7EjbpWclSr2LvgAGK0 mvtqfRu6xUGR8ONkMfdAFwLNeVw31ytVeiodECR0grhkVfMt0Cju529Fswa4rgkK7DRc wLvA== X-Received: by 10.152.42.172 with SMTP id p12mr42627440lal.11.1416411875122; Wed, 19 Nov 2014 07:44:35 -0800 (PST) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.171.73 with HTTP; Wed, 19 Nov 2014 07:44:14 -0800 (PST) In-Reply-To: References: From: Royce Williams Date: Wed, 19 Nov 2014 06:44:14 -0900 X-Google-Sender-Auth: 1xWx8YWt9XwSDZxFjReHoYpBLhM Message-ID: Subject: Re: best overall upgrade from 8.x? To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 15:44:37 -0000 On Mon, Nov 17, 2014 at 9:55 PM, Craig Rodrigues wrote: > On Fri, Nov 14, 2014 at 7:44 PM, Royce Williams wrote: >> >> I have some 8.x boxes that I'm looking to start planning to transition >> before 8.4 is likely to go EOL next year. >> >> All other things being equal, what's the general consensus on where to >> upgrade to from 8.x ... 9.x, or 10.x? The original intent of my question was not very clear. I happen to be tracking -RELEASE with freebsd-update, but my question was really intended to be a "which one is better, 9.x or 10.x?" rather than about how to perform the upgrade per se. > Do you have one of your machines available for experimentation to do > a test upgrade from 8.x to 10.1-RELEASE via freebsd-update, and also pkg_add > to pkgng? I do, though the systems in question are already using pkgng. > I would be curious what your experience with this would be, so that we can > fix documentation for doing such an upgrade. Fair enough! In a VM, I did a stock install of 8.4-RELEASE and then used freebsd-update to upgrade to 10.1-RELEASE. I tried to act like someone familiar with freebsd-update and FreeBSD 8.x (and below), but unaware of any issues specific to 9.x or 10.x upgrades. tl;dr: This was relatively painless, with a few freebsd-update cosmetic oddities that might throw off the uninitiated, and a nice hint from pkg to bootstrap itself. Walkthrough: I installed 8.4-RELEASE from the original release DVD ISO in a Virtualbox VM. Other than things like using the entire drive for FreeBSD and using automatic partitioning, I only enabled sshd and IPv4 DHCP, and installed packages bash, portmaster, screen, and sudo during the install. At first boot, I brought 8.4 current with: # freebsd-update fetch install ... which threw these errors: Installing updates...install: ///user/src/share/zoneinfo/leap-seconds.list: No such file or directory install: ///usr/src/share/zoneinfo/zone1970.tab: No such file or directory done. I then rebooted: # shutdown -r now ... which brought me to 8.4-RELEASE-p19. I then started an upgrade to 10.1: # freebsd-update -r 10.1-RELEASE upgrade This fetched 9400 patches and 10336 files. Changes that were merged: /etc/group: added unbound group. /etc/passwd: added unbound user. /etc/motd: updates to newbie guidance. /etc/master.passwd: added unbound user. Tag changes only: /etc/shells Continuing with the upgrade: # freebsd-update install ... produced this error: Installing updates...rmdir: ///boot/kernel: Directory not empty Continuing: # shutdown -r now ... rebooted to the expected kernel: 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 Continuing: # freebsd-update install ... after which I was prompted to rebuild all third-party software. This wasn't too hard, as I'd only installed bash, portmaster, screen, and sudo (and their dependencies libiconv and gettext). Attempting to run pkg, I got this helpful prompt: The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from [url], please wait... Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done Installing pkg-1.3.8_3: 100% Message for pkg-1.3.8_3: If you are upgrading from the old package format, first run: # pkg2ng I ran pkg2ng, with no errors. However, I had also neglected to install a ports tree: # portmaster -a ===>>> The ports directory ( make: stopped in /root) does not seem to contain a ports tree ==>>> Killing background jobs Terminated ===>>> Exiting ... so ... # portsnap fetch extract and then ... # portmaster -a ... which fetched as dependencies: devel/bison devel/gmake devel/m4 lang/perl5.16 ports-mgmt/dialog4ports print/indexinfo The package message for pkg prompted me to add "WITH_PKGNG=yes", to /etc/make.conf, so I did so. Unrelated to the vanilla upgrade, I was also prompted to add fdesc support for bash. So as prompted, I added to /etc/fstab: fdesc /dev/fd fdescfs rw 0 0 I then ran freebsd-update one more time: # freebsd-update install ... which completed with no errors. Royce From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 15:55:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B2AE360 for ; Wed, 19 Nov 2014 15:55:36 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 278BBAB0 for ; Wed, 19 Nov 2014 15:55:35 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id sAJFtXVN070655 for ; Wed, 19 Nov 2014 16:55:33 +0100 (CET) Received: from hausen-mbp-5.intern.punkt.de (hausen-mbp-5.intern.punkt.de [217.29.45.148]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id sAJFtXgV081103 for ; Wed, 19 Nov 2014 16:55:33 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: 10.1 geom "diskid" From: "Patrick M. Hausen" In-Reply-To: Date: Wed, 19 Nov 2014 16:55:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> References: To: "freebsd-stable@freebsd.org List" X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 15:55:36 -0000 Now it's getting decidedly weird: > Am 19.11.2014 um 16:40 schrieb Patrick M. Hausen : >=20 > Hi, all, >=20 > next question, sorry. I just created a fresh 10.1 installation > with ZFS. With the last reboot after adding dedicated SSD > based l2arc and zil, the underlying devices are referred to > by "diskid" instead of the GPT labels I have first been using: >=20 > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > logs > diskid/DISK-BTTV334403R7200GGNp2 ONLINE 0 0 0 > cache > diskid/DISK-BTTV334403R7200GGNp1 ONLINE 0 0 0 >=20 > I can live with that, but I do not understand why the ada2 device > changed from gpt/* to diskid/* while the others did not? >=20 > /dev/gpt entries are not even present for ada2, neither are ada2p? >=20 > At least the system could try to be consistent ;-) gnop create -S 4096 /dev/diskid/DISK-BTTV334403R7200GGNp3 zpool create ssd /dev/diskid/DISK-BTTV334403R7200GGNp3.nop zpool export ssd gnop destroy /dev/diskid/DISK-BTTV334403R7200GGNp3.nop zpool import ssd zpool status pool: ssd state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM ssd ONLINE 0 0 0 gpt/ssd ONLINE 0 0 0 errors: No known data errors WTF? Now it's referring to ada2p3 as gpt/ssd again. Of course the first = 2 partitions are still diskid/DISK-BTTV334403R7200GGNp1 and p2, since I have not changed anything about the "zroot" pool. OK, reboot ... zpool status ... NAME STATE READ WRITE CKSUM ssd ONLINE 0 0 0 diskid/DISK-BTTV334403R7200GGNp3 ONLINE 0 0 0 Now all 3 partitions on the SSD are addressed by diskid. The two mirror vdevs by GPT label, and, needless to say, the two components of my swap gmirror by legacy devices: root@seleniumhub:~ # gmirror status Name Status Components mirror/swap COMPLETE ada0p2 (ACTIVE) ada1p2 (ACTIVE) Although I created the mirror using /dev/gpt/swap0 and swap1, of course = ;-) Please do not consider this a major complaint. As long as everything = works, I'm perfectly happy. But I'd like to understand what is going on here. All the recent Ubuntu installs I run refer to disks exclusively by UUID = and here we have three different kinds of devices in a single install. That = *might* scare away someone some time ... Kind regards Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 16:01:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAE34594 for ; Wed, 19 Nov 2014 16:01:52 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C69FBBC for ; Wed, 19 Nov 2014 16:01:52 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id r20so9377804wiv.0 for ; Wed, 19 Nov 2014 08:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zu2PIgl6BqognpY+LnotrJUyZUPe9DwDSmU/PrAoFwk=; b=pOF/D/+eB4qC49B+Da+0PLzSppDb+UvS9LydrofnziDIN1zp6qB5Qk0y3j9uC5zvuc AHdcsTc2BvTGTqTEXAgGS52oDfGp9c9YjnbDkzTEks/TQneEe9hEfF64cmVlpN4Y4RNd PFYLtOdyeRzNKmZEyPHOl4CHznW4TulrPY9+GKUIe+8kz5oGiNozTC0kB9rAzz0o0Xwu fFh4FE3ONaCDqvZA8sqqPMVzsOZZzxzg5x1nrs+YTeUwJyRcMXuz+oLf72votgnoieeI AJyUxkzs4jTAuei82++ocHsNjbEDciQmIv3PbmzuSAy8WVM27xVM5SkAhtABINv3P2qg Q70g== MIME-Version: 1.0 X-Received: by 10.180.90.197 with SMTP id by5mr7108318wib.50.1416412910638; Wed, 19 Nov 2014 08:01:50 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.156.229 with HTTP; Wed, 19 Nov 2014 08:01:50 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Nov 2014 09:01:50 -0700 X-Google-Sender-Auth: qvX9TovHTbQwO9u7InB9ji7noMA Message-ID: Subject: Re: 10.1 geom "diskid" From: Alan Somers To: "Patrick M. Hausen" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org List" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 16:01:52 -0000 On Wed, Nov 19, 2014 at 8:40 AM, Patrick M. Hausen wrote: > Hi, all, > > next question, sorry. I just created a fresh 10.1 installation > with ZFS. With the last reboot after adding dedicated SSD > based l2arc and zil, the underlying devices are referred to > by "diskid" instead of the GPT labels I have first been using: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > logs > diskid/DISK-BTTV334403R7200GGNp2 ONLINE 0 0 0 > cache > diskid/DISK-BTTV334403R7200GGNp1 ONLINE 0 0 0 > > I can live with that, but I do not understand why the ada2 device > changed from gpt/* to diskid/* while the others did not? > > /dev/gpt entries are not even present for ada2, neither are ada2p? > > At least the system could try to be consistent ;-) When ZFS imports a pool, it tries to open each vdev by name. If it can't find the vdev's name, or if that devname now refers to some other provider, then ZFS searches through every geom provider to find the ones with the right label. Sometimes it finds /dev/da* first, sometimes it finds /dev/gpt/* first, and sometimes it finds /dev/diskid/* first. That's why it seems inconsistent. If you want to force some consistency, you can set these tunables in /boot/loader.conf.local. That way ZFS will only be able to use the /dev/da* and /dev/ada* devnames. kern.geom.label.disk_ident.enable=0 kern.geom.label.gptid.enable=0 Or, if you specify the /dev/diskid/* or /dev/gpt/* devnames in the zpool create command, then those devnames should get written to the label, and ZFS will always use them when it imports a pool. At least, I think that it will. I haven't tested it myself. -Alan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 16:02:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33049695; Wed, 19 Nov 2014 16:02:52 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DA44BD4; Wed, 19 Nov 2014 16:02:51 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id hs14so745760lab.22 for ; Wed, 19 Nov 2014 08:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uXtUwO8QHNXjK4KUBlTXiHVlrf6009vVo8URap+rwa0=; b=t3i3SWxAFeQETo+XQ1TXGfI+q2vSenCvbYZD76X3fhR/8wo5mdJ35tvmR60I8ZPjRO KC1y6hyWQFYJDkDKXhdPUoF3tr3K4eC7+P4XdXjcTV1K4uyvTWaxZGNoKnLo6An2I5UH r8FGet7rCjLKZb1DKrurgwoMdUiO2ME+uR2SQdhw1LQfy4/PJJG5yMqTAfYN/M+AK1IH Azrj5rjqk/h3wGDW8OGulf4ZdAmm6Z8CH4z9fMlzWZBapa9xleULyaBZawE5XMRy2sg+ EPlUWmc1a7dibYAiC2RD21k3cv87IpX/0DrALI9oDWLQFUjRE3+6sr5mKe5RWtgaR0da IDrg== MIME-Version: 1.0 X-Received: by 10.112.133.138 with SMTP id pc10mr6189601lbb.48.1416412969552; Wed, 19 Nov 2014 08:02:49 -0800 (PST) Received: by 10.25.170.66 with HTTP; Wed, 19 Nov 2014 08:02:49 -0800 (PST) In-Reply-To: References: <3C955A8F-9D1A-463B-BB9A-256C36BF0D4C@gromit.dlib.vt.edu> Date: Wed, 19 Nov 2014 17:02:49 +0100 Message-ID: Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles From: Andreas Nilsson To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Daniel O'Connor , FreeBSD Stable Mailing List , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 16:02:52 -0000 On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson wrote: > > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky wrote: > >> Daniel, >> >> nice to see you here too ;) >> >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: >> >> > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson wrote: >> > > unclear is the word for it :) And thanks for looking into this. >> ipmi/ilo is >> > > important on a server os. >> > > >> > > I found a reference to it in a ML post: >> > > >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.html >> > >> > I started that thread :) >> > I did get it working on the hardware I was using (Supermicro X9SCL-F >> and X8SIL-F) >> > >> > I used the following BIOS settings >> > ? Remote Access - Enabled >> > ? Serial Port Number - COM3 >> > ? Serial Port Mode - 115200, 8, n, 1 >> > ? Flow Control - Hardware >> > ? Redirection After BIOS POST - Always >> > ? Terminal Type - VT100 >> > ? VT-UTF8 Combo Key Support - Disabled >> > ? Sredir Memory Display Delay - No Delay >> > >> > And the following in loader.conf >> > # Give preference to VGA console >> > console="vidconsole,comconsole" >> > # Uncomment below and comment above to give serial console preference >> > #console="comconsole,vidconsole" >> > comconsole_speed="115200" >> > boot_multicons="YES" >> > hint.uart.0.flags="0x0" >> > hint.uart.2.at="isa" >> > hint.uart.2.port="0x3E8" >> > hint.uart.2.flags="0x30" >> > >> > And this in /etc/ttys >> > # IPMI console >> > # Note: The Java console viewer doesn't seem to be very smart as it >> doesn't >> > # properly support VT100 >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on secure >> > >> > I could then access it using ipmitool like so >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate >> > [login] >> > export TERM=xterm >> > >> > Note that I wanted vidconsole by default because mostly the systems >> were used by people local to them, however we could break into the loader >> and type 'set console=comconsole,vidconsole? and then get everything over >> the serial console for remote trouble shooting. >> > >> > You may also wish to check the IPMI configuration via the web interface >> - by default it will failover to port 0 and it has terrible default >> passwords. I changed the passwords and forced it to use the dedicated IPMI >> port even if nothing was connected to it. >> >> Well, I'm almost done with most of our SM server, even concentrated >> console on >> our console server with such a simple config: >> >> ---- 8< ---- >> # ipmi/sol console template >> default ipmi { >> master localhost; >> type exec; >> exec /usr/local/bin/ipmitool -f /usr/local/etc/ipmi-pass -U >> root -I lanplus -H %.int sol activate; >> execsubst %=cs; >> #idletimeout 6h; >> >> break 0 { string "~B"; } >> } >> >> console gwn1 { include ipmi; } >> console gwn2 { include ipmi; } >> console gwn3 { include ipmi; } >> console gwn4 { include ipmi; } >> console gwn5 { include ipmi; } >> console gwn6 { include ipmi; } >> console gwn7 { include ipmi; } >> console gwn8 { include ipmi; } >> >> console gwc2 { include ipmi; } >> ---- 8< ---- >> >> This has console logging (including possible panics) as a surplus >> >> -- >> Sincerely, >> D.Marck [DM5020, MCK-RIPE, DM3-RIPN] >> [ FreeBSD committer: marck@FreeBSD.org ] >> ------------------------------------------------------------------------ >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** >> ------------------------------------------------------------------------ >> > > Hello again, > > Searching on hw.uart.console, I found: > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > , a very enlightening thread. > > Basically: "ohh, you want to use something other than COM1 and tried to > get away with just changing hint.uart stuff, which has worked for a while, > ha, no way..." No heads up, nothing. > > Sorry to say jhb@ but is not a rare case. It is if not the default, a > very common setup on every HP server with iLO, and it holds for most all > OOB style serial emulation I have ever had the (dis)pleasure of working > with. > > Best regards > Andreas > > > More fun stuff: On the supermicro machine it is not working to use comconsole_port, as it seems to switch, "redirect after boot" I guess. Specifying hw.uart.console="br:9600" works though, but how to specify that via comconsole_port? (hint, do not put comconsole_port="" in loader.conf) Regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 16:08:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CE079F8 for ; Wed, 19 Nov 2014 16:08:26 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40CB8C42 for ; Wed, 19 Nov 2014 16:08:26 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y19so1166795wgg.28 for ; Wed, 19 Nov 2014 08:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0R5GLoKdkMwyzllFmOLVuCR/CSgUB7Pk2PnfuiKJBe4=; b=EVFNv0Nzew9tYAhZxf5lejeXZwY8CWWTwR4EDRNfrbDysIOIydYWEc4KZa9xY+ve6a JUEyQo4lGaisE3PpSdTtG8h78XuVcB+He2lXF7LPgdfEjyPyrK43VLdpPl5plki5vnwt v4YiTsPsl4f4oWZJrPBlkJJxBvLYyQb8aDQodeXYW5rh3HfZyCVV5pAJP+4ru4D77d0O 5wVDl0ZojpyqXA3tah2/gIzLsDngpZ/onWZax5O0Acr3CXdkV2dqDupnyN5Cgshbrh9J n6xKJB5sxk8HHhUQdXrjVY79Y3d35Yoys7Xj2eviWM8Ipc+H/RNgwpKqJLD98XFB2h13 lxBQ== MIME-Version: 1.0 X-Received: by 10.180.8.34 with SMTP id o2mr6861798wia.23.1416413298952; Wed, 19 Nov 2014 08:08:18 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.156.229 with HTTP; Wed, 19 Nov 2014 08:08:18 -0800 (PST) In-Reply-To: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> References: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> Date: Wed, 19 Nov 2014 09:08:18 -0700 X-Google-Sender-Auth: g4wZRdvTf1u0mQN3phnk8fi_s6M Message-ID: Subject: Re: 10.1 geom "diskid" From: Alan Somers To: "Patrick M. Hausen" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org List" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 16:08:26 -0000 On Wed, Nov 19, 2014 at 8:55 AM, Patrick M. Hausen wrote: > Now it's getting decidedly weird: > >> Am 19.11.2014 um 16:40 schrieb Patrick M. Hausen : >> >> Hi, all, >> >> next question, sorry. I just created a fresh 10.1 installation >> with ZFS. With the last reboot after adding dedicated SSD >> based l2arc and zil, the underlying devices are referred to >> by "diskid" instead of the GPT labels I have first been using: >> >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/disk0 ONLINE 0 0 0 >> gpt/disk1 ONLINE 0 0 0 >> logs >> diskid/DISK-BTTV334403R7200GGNp2 ONLINE 0 0 0 >> cache >> diskid/DISK-BTTV334403R7200GGNp1 ONLINE 0 0 0 >> >> I can live with that, but I do not understand why the ada2 device >> changed from gpt/* to diskid/* while the others did not? >> >> /dev/gpt entries are not even present for ada2, neither are ada2p? >> >> At least the system could try to be consistent ;-) > > gnop create -S 4096 /dev/diskid/DISK-BTTV334403R7200GGNp3 > zpool create ssd /dev/diskid/DISK-BTTV334403R7200GGNp3.nop > zpool export ssd > gnop destroy /dev/diskid/DISK-BTTV334403R7200GGNp3.nop > zpool import ssd > zpool status Why the gnop acrobatics? It seems that you are trying to force ZFS to treat the disk as though it has 4K sectors. Normally ZFS will use the correct physical sector size as reported by the disk. Have you checked whether it reports it sectorsize correctly? Do "diskinfo -v /devdiskid/DISK-BTTV334403R7200GGNp3" and look for the "stripesize" value. It will probably say either 0 for a 512B drive or 4096 for a 4K drive. If it says 0, and you have accurate information that the true physical sector size is 4K, then we should update the quirk tables in the da and ada drivers. -Alan > > pool: ssd > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > ssd ONLINE 0 0 0 > gpt/ssd ONLINE 0 0 0 > > errors: No known data errors > > > WTF? Now it's referring to ada2p3 as gpt/ssd again. Of course the first 2 > partitions are still diskid/DISK-BTTV334403R7200GGNp1 and p2, since > I have not changed anything about the "zroot" pool. > > OK, reboot ... > > zpool status > ... > NAME STATE READ WRITE CKSUM > ssd ONLINE 0 0 0 > diskid/DISK-BTTV334403R7200GGNp3 ONLINE 0 0 0 > > Now all 3 partitions on the SSD are addressed by diskid. The two mirror > vdevs by GPT label, and, needless to say, the two components of my swap > gmirror by legacy devices: > > root@seleniumhub:~ # gmirror status > Name Status Components > mirror/swap COMPLETE ada0p2 (ACTIVE) > ada1p2 (ACTIVE) > > Although I created the mirror using /dev/gpt/swap0 and swap1, of course ;= -) > > > Please do not consider this a major complaint. As long as everything work= s, > I'm perfectly happy. But I'd like to understand what is going on here. > All the recent Ubuntu installs I run refer to disks exclusively by UUID a= nd here > we have three different kinds of devices in a single install. That *might= * > scare away someone some time ... > > > Kind regards > Patrick > -- > punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe > Tel. 0721 9109 0 * Fax 0721 9109 100 > info@punkt.de http://www.punkt.de > Gf: J=C3=BCrgen Egeling AG Mannheim 108285 > _______________________________________________ > 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 Wed Nov 19 16:19:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94799236; Wed, 19 Nov 2014 16:19:42 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492F6D8F; Wed, 19 Nov 2014 16:19:42 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jjTkM607Cz14J; Wed, 19 Nov 2014 17:19:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:organization:subject:subject:from:from :date:date:content-transfer-encoding:content-type:content-type :mime-version:received:received:received:received; s=jakla4; t= 1416413976; x=1419005977; bh=+plmnk8uodeRCIj/NJoYgD8YCymZqdTJeuZ vFAgp8Cg=; b=jwAjt2gQJWhhOe40L2Iva6CmoUhdsCUlmZ4pSxS5VSeZ6gRsOrU BaQ6LkBEh5QERNPhE9NUpzobWnvCGYEmE91xw1VboX+DnU1Un+5t3f0b5OUJS3W6 SlYvJZAnq7bX0OEfaFPCIi22u0gzzcYF/CEdsnYQcKvudYa9YzhffR8g= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 9WtRZ9Yezewr; Wed, 19 Nov 2014 17:19:36 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Wed, 19 Nov 2014 17:19:35 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jjTkH5hNTzns; Wed, 19 Nov 2014 17:19:35 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 19 Nov 2014 17:19:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2014 17:19:35 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: DANE & DNSSEC @ freebsd.org - good job! Organization: J. Stefan Institute Message-ID: <8337e5521768bdf3cd959fc0e063dd83@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 16:19:42 -0000 Just want to say I was pleasantly surprised seeing that the mailer at freebsd.org now supports DANE [1]. Good job guys and gals!!! Nov 19 16:07:05 dorothy postfix/smtp[68423]: Verified TLS connection established to mx1.freebsd.org[2001:1900:2254:206a::19:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) (sorry for not being able to find a better ML for this posting) Mark [1] http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 16:46:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6391D63; Wed, 19 Nov 2014 16:46:49 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9620510E; Wed, 19 Nov 2014 16:46:49 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id va2so712664obc.22 for ; Wed, 19 Nov 2014 08:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aGCer0g3HWDXIAXGXDE9EJpOPbejQefcum+Y2liUEdA=; b=Ks0UVtKPjd6HWmyAh1FY+XmmxlFgHtfn/EbF6eNsKoCn38Rr46+9dzD5b7dBBpnLHZ ubJD8dsEULcso4BWFXtYiP5EhXLUfcdPQobxUKwbZbBBXMoFmAx6+4ShnracvDGs2NzT hhyDCQecgGxlqy4Ss8HgoBAS53IzlmguSF5lvSQdvy6N6P50jMr5SnN50DuOXkxZkr2G cb2O458AN5rKG3CZSdGN+ZlF1R+i8JejFQTixxbWOP7ZzR42l1Cn9lNOb5K9gB5GxDSY Coau5LRasXisQh2+ak0GUnT3wDX8CKxND06/ew8ddOHzSY8nnwxTkKN8RDebWaoB5uwd aiGw== MIME-Version: 1.0 X-Received: by 10.60.67.70 with SMTP id l6mr1109066oet.76.1416415567801; Wed, 19 Nov 2014 08:46:07 -0800 (PST) Received: by 10.202.6.21 with HTTP; Wed, 19 Nov 2014 08:46:07 -0800 (PST) In-Reply-To: References: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> Date: Wed, 19 Nov 2014 08:46:07 -0800 Message-ID: Subject: Re: 10.1 geom "diskid" From: Freddie Cash To: Alan Somers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-stable@freebsd.org List" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 16:46:49 -0000 On Wed, Nov 19, 2014 at 8:08 AM, Alan Somers wrote: > On Wed, Nov 19, 2014 at 8:55 AM, Patrick M. Hausen > wrote: > > Now it's getting decidedly weird: > > > >> Am 19.11.2014 um 16:40 schrieb Patrick M. Hausen : > >> > >> Hi, all, > >> > >> next question, sorry. I just created a fresh 10.1 installation > >> with ZFS. With the last reboot after adding dedicated SSD > >> based l2arc and zil, the underlying devices are referred to > >> by "diskid" instead of the GPT labels I have first been using: > >> > >> NAME STATE READ WRITE CKSUM > >> zroot ONLINE 0 0 0 > >> mirror-0 ONLINE 0 0 0 > >> gpt/disk0 ONLINE 0 0 0 > >> gpt/disk1 ONLINE 0 0 0 > >> logs > >> diskid/DISK-BTTV334403R7200GGNp2 ONLINE 0 0 0 > >> cache > >> diskid/DISK-BTTV334403R7200GGNp1 ONLINE 0 0 0 > >> > >> I can live with that, but I do not understand why the ada2 device > >> changed from gpt/* to diskid/* while the others did not? > >> > >> /dev/gpt entries are not even present for ada2, neither are ada2p? > >> > >> At least the system could try to be consistent ;-) > > > > gnop create -S 4096 /dev/diskid/DISK-BTTV334403R7200GGNp3 > > zpool create ssd /dev/diskid/DISK-BTTV334403R7200GGNp3.nop > > zpool export ssd > > gnop destroy /dev/diskid/DISK-BTTV334403R7200GGNp3.nop > > zpool import ssd > > zpool status > > > Why the gnop acrobatics? =E2=80=8BFuture-proofing the pool. :) It's going to get harder and harder= to buy 512B harddrives, meaning that at some point, the drives will be replaced with 4K drives, and performance will (potentially) tank on the pool=E2=80= =8B. If you build the pool from the get-go with an ashift of 12 (4K sectors), then you won't have any issues in the future. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 16:50:38 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75202E9A; Wed, 19 Nov 2014 16:50:38 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EBB41CC; Wed, 19 Nov 2014 16:50:38 +0000 (UTC) Received: from gromit.chumby.lan (c-71-63-94-21.hsd1.va.comcast.net [71.63.94.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id C5ADAAC9; Wed, 19 Nov 2014 11:41:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles From: Paul Mather In-Reply-To: Date: Wed, 19 Nov 2014 11:41:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9CC9B190-9645-4AE3-B3CF-3C38386D1601@gromit.dlib.vt.edu> References: <3C955A8F-9D1A-463B-BB9A-256C36BF0D4C@gromit.dlib.vt.edu> To: Andreas Nilsson X-Mailer: Apple Mail (2.1878.6) Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 16:50:38 -0000 On Nov 19, 2014, at 11:02 AM, Andreas Nilsson = wrote: > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson = wrote: >=20 >>=20 >>=20 >> On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky = wrote: >>=20 >>> Daniel, >>>=20 >>> nice to see you here too ;) >>>=20 >>> On Fri, 14 Nov 2014, Daniel O'Connor wrote: >>>=20 >>>>=20 >>>> On 12 Nov 2014, at 19:43, Andreas Nilsson = wrote: >>>>> unclear is the word for it :) And thanks for looking into this. >>> ipmi/ilo is >>>>> important on a server os. >>>>>=20 >>>>> I found a reference to it in a ML post: >>>>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.htm= l >>>>=20 >>>> I started that thread :) >>>> I did get it working on the hardware I was using (Supermicro = X9SCL-F >>> and X8SIL-F) >>>>=20 >>>> I used the following BIOS settings >>>> ? Remote Access - Enabled >>>> ? Serial Port Number - COM3 >>>> ? Serial Port Mode - 115200, 8, n, 1 >>>> ? Flow Control - Hardware >>>> ? Redirection After BIOS POST - Always >>>> ? Terminal Type - VT100 >>>> ? VT-UTF8 Combo Key Support - Disabled >>>> ? Sredir Memory Display Delay - No Delay >>>>=20 >>>> And the following in loader.conf >>>> # Give preference to VGA console >>>> console=3D"vidconsole,comconsole" >>>> # Uncomment below and comment above to give serial console = preference >>>> #console=3D"comconsole,vidconsole" >>>> comconsole_speed=3D"115200" >>>> boot_multicons=3D"YES" >>>> hint.uart.0.flags=3D"0x0" >>>> hint.uart.2.at=3D"isa" >>>> hint.uart.2.port=3D"0x3E8" >>>> hint.uart.2.flags=3D"0x30" >>>>=20 >>>> And this in /etc/ttys >>>> # IPMI console >>>> # Note: The Java console viewer doesn't seem to be very smart as it >>> doesn't >>>> # properly support VT100 >>>> cuau2 "/usr/libexec/getty 3wire.115200" vt100 on secure >>>>=20 >>>> I could then access it using ipmitool like so >>>> ipmitool -H remoteip -U ADMIN -I lanplus sol activate >>>> [login] >>>> export TERM=3Dxterm >>>>=20 >>>> Note that I wanted vidconsole by default because mostly the systems >>> were used by people local to them, however we could break into the = loader >>> and type 'set console=3Dcomconsole,vidconsole? and then get = everything over >>> the serial console for remote trouble shooting. >>>>=20 >>>> You may also wish to check the IPMI configuration via the web = interface >>> - by default it will failover to port 0 and it has terrible default >>> passwords. I changed the passwords and forced it to use the = dedicated IPMI >>> port even if nothing was connected to it. >>>=20 >>> Well, I'm almost done with most of our SM server, even concentrated >>> console on >>> our console server with such a simple config: >>>=20 >>> ---- 8< ---- >>> # ipmi/sol console template >>> default ipmi { >>> master localhost; >>> type exec; >>> exec /usr/local/bin/ipmitool -f /usr/local/etc/ipmi-pass = -U >>> root -I lanplus -H %.int sol activate; >>> execsubst %=3Dcs; >>> #idletimeout 6h; >>>=20 >>> break 0 { string "~B"; } >>> } >>>=20 >>> console gwn1 { include ipmi; } >>> console gwn2 { include ipmi; } >>> console gwn3 { include ipmi; } >>> console gwn4 { include ipmi; } >>> console gwn5 { include ipmi; } >>> console gwn6 { include ipmi; } >>> console gwn7 { include ipmi; } >>> console gwn8 { include ipmi; } >>>=20 >>> console gwc2 { include ipmi; } >>> ---- 8< ---- >>>=20 >>> This has console logging (including possible panics) as a surplus >>>=20 >>> -- >>> Sincerely, >>> D.Marck [DM5020, MCK-RIPE, = DM3-RIPN] >>> [ FreeBSD committer: = marck@FreeBSD.org ] >>> = ------------------------------------------------------------------------ >>> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru = *** >>> = ------------------------------------------------------------------------ >>>=20 >>=20 >> Hello again, >>=20 >> Searching on hw.uart.console, I found: >> = http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html >> , a very enlightening thread. >>=20 >> Basically: "ohh, you want to use something other than COM1 and tried = to >> get away with just changing hint.uart stuff, which has worked for a = while, >> ha, no way..." No heads up, nothing. >>=20 >> Sorry to say jhb@ but is not a rare case. It is if not the default, a >> very common setup on every HP server with iLO, and it holds for most = all >> OOB style serial emulation I have ever had the (dis)pleasure of = working >> with. >>=20 >> Best regards >> Andreas >>=20 >>=20 >>=20 > More fun stuff: > On the supermicro machine it is not working to use comconsole_port, as = it > seems to switch, "redirect after boot" I guess. >=20 > Specifying hw.uart.console=3D"br:9600" works though, but how to = specify that > via comconsole_port? (hint, do not put comconsole_port=3D"" in = loader.conf) In my experience it can be confusing to determine which COM port the = server is actually using for SOL. On multiple different Supermicro = servers, I've found the BIOS differs as to how SOL is set up. OFten, = you can't explicitly assign the COM port in the SOL setup. I've also = found it rare that the BIOS is explicit as to which COM port is being = used for SOL. I've had servers that use COM1, others that use COM2, and = others that use COM3. That makes setting comconsole_port somewhat a = process of trial and error, at least that's what I've found... Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 17:07:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62F76645 for ; Wed, 19 Nov 2014 17:07:17 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4AA938A for ; Wed, 19 Nov 2014 17:07:16 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id pn19so866534lab.26 for ; Wed, 19 Nov 2014 09:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eEZaD8o3ga+ftuMTFImw0WYYIoSfxS1W/E06HB+uAv8=; b=Kaq6BL/NMY65nRUm3QSxVNkLm/Ll0yiJM5g9IhawtreCkoGqNedDJPZaKFiqpHjZZ2 tbXQSF0ZMhCM70mvwhx/AieoJdrIXFKLSzM2L3XzGmtaliZl+TUD32d67rp/HPD5wm7C ov7iS4MANSm8EkqWszac5ZbBxM7GNP9s5wwbN+md5wyHNYuDJ4m/Iszd7oDuD3W/CAAI kfq6eNaRR1VUVXuZub2HqymL6ai0ORRQFLwSE/rKHWSpPBaaj9VOndTvDkRwDn7ryynF EH+gTrB14XDDTEnqY4AbD4airv/R9rvj/lRkv84obToYrmkK9D4hqMqe67wjwR/DMvgY xu1Q== MIME-Version: 1.0 X-Received: by 10.152.37.69 with SMTP id w5mr6322188laj.67.1416416833883; Wed, 19 Nov 2014 09:07:13 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Wed, 19 Nov 2014 09:07:13 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Nov 2014 09:07:13 -0800 X-Google-Sender-Auth: YkxuKLyxJYM5TLC3BjmQzc7nAlw Message-ID: Subject: Re: best overall upgrade from 8.x? From: Craig Rodrigues To: Royce Williams Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 17:07:17 -0000 On Wed, Nov 19, 2014 at 7:44 AM, Royce Williams wrote: > # portmaster -a > > > ... which fetched as dependencies: > > devel/bison > devel/gmake > devel/m4 > lang/perl5.16 > ports-mgmt/dialog4ports > print/indexinfo > > > Hi, Wow thank you for posting a step-by-step description of your upgrade experience! It is definitely helpful to other people. In your steps, you rebuilt all your ports with portmaster. It's good to confirm that works. Have you ever tried an upgrade scenario of: (1) Start with 8.4 system and about 200-300 old-style pkg_add packages installed. (2) Do freebsd update to 10.1, reboot into 10.1 with the old packages installed. (3) Run /usr/sbin/pkg to bootstrap the pkg utility (4) Run the pkg2ng utility to convert old-style package metadata to new packages (5) Run "pkg upgrade" to upgrade all your ports Does that sound like a viable upgrade path to you? I haven't tried it, but in theory it should work. Are those steps obvious from the existing sources of documentation that you did to do such an upgrade? -- Craig -- Craig From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 18:17:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93C71D6F for ; Wed, 19 Nov 2014 18:17:39 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A557D57 for ; Wed, 19 Nov 2014 18:17:38 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y19so1538714wgg.0 for ; Wed, 19 Nov 2014 10:17:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RLIRebjc3eQaxwbSDqoKaUNDZDOys2yPiF3E4hYVtb8=; b=Kjwk39fR7v3IIyb5AaRq+IR6bAZyhKt6LR7c2aYcrSytCE1y1DJNrf2zYFqZW8MPpT rnswChSs3sPOU5GUGlWzx/ZfwYOstNfOkhLWfW7P/S6SSPx3fc5raLFzdgfxj3nfwO1S EOz96b4ZOFvQXZ4XRJkSgdv8jot+mH0MNbRUupzIu/4kSKeSEMqDJed46gcarH+gMpU/ FX96PTi7/ZVOosIBMvKCwWgUlS/fBn7v4eQmKp8QQMUrjJISuCHh5q/iaI+RUCXmx3Ln +EmhOAT/iUotGa4Qda/NuXoKCg/lzVPjolpo1orzGluwdFT4H70ioObE5jajYicva7Cs ot1w== X-Gm-Message-State: ALoCoQn0q3R8LedTpmC1LFCeJGU+AK06qhsxC7QoLzPTiPbZ+B4Go52m50N/Ln5qx6bF1UfMYUUH X-Received: by 10.180.187.67 with SMTP id fq3mr15456753wic.37.1416421051248; Wed, 19 Nov 2014 10:17:31 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fq1sm3227637wib.12.2014.11.19.10.17.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Nov 2014 10:17:30 -0800 (PST) Message-ID: <546CDED8.7040902@multiplay.co.uk> Date: Wed, 19 Nov 2014 18:18:00 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1 geom "diskid" References: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> In-Reply-To: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 18:17:39 -0000 On 19/11/2014 15:55, Patrick M. Hausen wrote: > Now it's getting decidedly weird: > >> Am 19.11.2014 um 16:40 schrieb Patrick M. Hausen : >> >> Hi, all, >> >> next question, sorry. I just created a fresh 10.1 installation >> with ZFS. With the last reboot after adding dedicated SSD >> based l2arc and zil, the underlying devices are referred to >> by "diskid" instead of the GPT labels I have first been using: >> >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/disk0 ONLINE 0 0 0 >> gpt/disk1 ONLINE 0 0 0 >> logs >> diskid/DISK-BTTV334403R7200GGNp2 ONLINE 0 0 0 >> cache >> diskid/DISK-BTTV334403R7200GGNp1 ONLINE 0 0 0 >> >> I can live with that, but I do not understand why the ada2 device >> changed from gpt/* to diskid/* while the others did not? >> >> /dev/gpt entries are not even present for ada2, neither are ada2p? >> >> At least the system could try to be consistent ;-) > gnop create -S 4096 /dev/diskid/DISK-BTTV334403R7200GGNp3 > zpool create ssd /dev/diskid/DISK-BTTV334403R7200GGNp3.nop > zpool export ssd > gnop destroy /dev/diskid/DISK-BTTV334403R7200GGNp3.nop > zpool import ssd > zpool status As a matter of reference you dont need to do this anymore, instead use: sysctl vfs.zfs.min_auto_ashift=12 before creating the pool. Regards Steve From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 18:51:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46038B3B for ; Wed, 19 Nov 2014 18:51:33 +0000 (UTC) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05B93E7 for ; Wed, 19 Nov 2014 18:51:32 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id w8so820904qac.37 for ; Wed, 19 Nov 2014 10:51:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mFDpeeROwVSayrUCvf9yRELenu7i8eKJmiWGe7e6sik=; b=ezXbmtkUUvzvvtYtlBnY59/GrbDe7yjP+IhMvCMag7reP5v31t3gDkp+r4O5qTaGFS DzIP0qLP9HR+Mr4woX/NjN1XhRswEgynsWo/4D3nUgx88XQ6j3UoODvmwvTvGdN3CXf9 EvWBEjD2FPTGsFv6LeZcWtGP7CICwSqrKo5ucKMGFCBlw5ZIpv0+Obwk8bKLseL+zpfc 83/7RamzPVClVfX19RgAi8Ii6t3raMEiPHnVZscXAHjKIDaAEJzQ/m4AXC5fSGrdhgyZ b+4VW2FdXDdQysGZRzlD/l7ykB7ewZlrdLTdMY0ebSBtfqdiPYzmrOONC2qNr5ksn5Dm SdLA== X-Gm-Message-State: ALoCoQlAoG3WtKxWuIPkdMbhPZcKHwv2CTKNVcbz798Z5tydy6HnHPc4JUsEg0Xva0CwgEmwgNa3 MIME-Version: 1.0 X-Received: by 10.224.167.132 with SMTP id q4mr52874214qay.48.1416422662339; Wed, 19 Nov 2014 10:44:22 -0800 (PST) Received: by 10.229.14.4 with HTTP; Wed, 19 Nov 2014 10:44:22 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Nov 2014 12:44:22 -0600 Message-ID: Subject: Re: 10.1 fresh install and 4k alignment From: Aidan Scheller To: Mark Martinec Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 18:51:33 -0000 Hi Mark, Did you submit a PR for this? I'm not able to find anything related in Bugzilla and am wondering we should do so. Thanks, Aidan On Wed, Nov 19, 2014 at 8:32 AM, Mark Martinec wrote: > Patrick M. Hausen wrote: > >> Hi, all, >> >> I just installed a new machine with 10.1-RELEASE using the memstick >> installer >> and chosing ZFS mirror root as the disk layout. >> >> I did check the "4k" option, watched the installer do the necessary gnop >> dance >> and the pool seems to be OK: >> >> root@seleniumhub:~ # zdb | grep ashift >> ashift: 12 >> >> But this puzzles me a bit: >> >> root@seleniumhub:~ # gpart list ada0 >> Mediasize: 524288 (512K) >> Sectorsize: 512 >> ... >> Providers: >> 1. Name: ada0p1 >> Mediasize: 524288 (512K) >> Sectorsize: 512 >> ... >> end: 1057 >> start: 34 >> ... >> 3. Name: ada0p3 >> Mediasize: 465747565056 (434G) >> Sectorsize: 512 >> ... >> type: freebsd-zfs >> ... >> end: 976773134 >> start: 67109922 >> >> None of the start sector numbers is a multiple of 8, neither are the end >> sectors >> a multiple of 8 minus 1. >> >> So the pool uses a 4k block size but it starts on an odd multiple of >> 2k on the platter >> - do I see this correctly? >> >> Isn't it absolutely necessary that the simulated 4k blocks are laid >> out so that the first >> is made from 512 byte sectors 0-7, the second from 8-15 and so on? >> >> Then why does the installer start the first partition at 512 byte >> sector 34? While I'm at >> it, this magic number is everywhere in the older documentation, e.g. >> for manually >> installing FreeBSD 8 with gptzfsboot - where does that 34 come from? It's >> not >> a power of 2 nor is it one of the historical CHS magic numbers that would >> mean >> a cylinder boundary or similar. Size of the GPT partition table itself? >> >> Is this a bug in the installer? Will I still have to layout the disks >> manually if I want 4k >> alignment? What's a good offset for the first partition in this case? >> Anything bigger >> than 34 that's a multiple of 8 - 40 or 64? >> >> Thanks in advance >> Patrick >> > > > Reported on 2014-10-10, but was apparently forgotten/ignored: > > "GPT partitions not 4k aligned by 10.1-RC1 installer" > https://lists.freebsd.org/pipermail/freebsd-stable/2014- > October/080509.html > > > Mark > > > > _______________________________________________ > 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 Wed Nov 19 18:55:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6380E48; Wed, 19 Nov 2014 18:55:33 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24EFC1B6; Wed, 19 Nov 2014 18:55:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAJIt3mj026745; Wed, 19 Nov 2014 21:55:03 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 19 Nov 2014 21:55:03 +0300 (MSK) From: Dmitry Morozovsky To: Paul Mather Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles In-Reply-To: <9CC9B190-9645-4AE3-B3CF-3C38386D1601@gromit.dlib.vt.edu> Message-ID: References: <3C955A8F-9D1A-463B-BB9A-256C36BF0D4C@gromit.dlib.vt.edu> <9CC9B190-9645-4AE3-B3CF-3C38386D1601@gromit.dlib.vt.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 19 Nov 2014 21:55:04 +0300 (MSK) Cc: Daniel O'Connor , FreeBSD Stable Mailing List , John Baldwin , Andreas Nilsson X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 18:55:33 -0000 On Wed, 19 Nov 2014, Paul Mather wrote: [snip all previous] > > More fun stuff: > > On the supermicro machine it is not working to use comconsole_port, as it > > seems to switch, "redirect after boot" I guess. > > > > Specifying hw.uart.console="br:9600" works though, but how to specify that > > via comconsole_port? (hint, do not put comconsole_port="" in loader.conf) > > In my experience it can be confusing to determine which COM port the server > is actually using for SOL. On multiple different Supermicro servers, I've > found the BIOS differs as to how SOL is set up. OFten, you can't explicitly > assign the COM port in the SOL setup. I've also found it rare that the BIOS > is explicit as to which COM port is being used for SOL. I've had servers > that use COM1, others that use COM2, and others that use COM3. That makes > setting comconsole_port somewhat a process of trial and error, at least > that's what I've found... I'm now as a thumbrule (well, no servers older tan, say, 6-8 years) use output of grep uart /var/run/dmesg.boot and, usually, IPMI/SOL is the last one from the output; also, you can use port/irq from there in corner cases -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 19:12:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64CABA9C for ; Wed, 19 Nov 2014 19:12:08 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1372660C for ; Wed, 19 Nov 2014 19:12:07 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3jjYYJ0y4xz16m for ; Wed, 19 Nov 2014 20:12:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1416424320; x=1419016321; bh=ZRc y+RW9I27eaR/bkIY0GStoN0jBUZwbqyPdOnIyirk=; b=ROaOiXuvgkZlZhckUM/ Y1DOzNIIe3dOUu7192oSJQK9jakSxTWdTys+NTIhBpsSHiuLLr3DepVyVNt/9xGz 1NTITL4J+NaH+BW4UksSaDt3qzLcKumrIE43BQQJkM0+OAhJQJNgQqprlvKddEBE Pgnyiq0QSbGhyjs4n657bs/0= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id kUeUHcP8qInQ for ; Wed, 19 Nov 2014 20:12:00 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 19 Nov 2014 20:12:00 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3jjYYD5VZJz82 for ; Wed, 19 Nov 2014 20:12:00 +0100 (CET) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 19 Nov 2014 20:12:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2014 20:12:00 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org Subject: Re: 10.1 fresh install and 4k alignment Organization: J. Stefan Institute In-Reply-To: References: Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:12:08 -0000 Aidan Scheller wrote: > Hi Mark, > Did you submit a PR for this? I'm not able to find anything related in > Bugzilla and am wondering we should do so. You are quite right, what isn't in Bugzilla does not exist. I did file the report just now: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195174 Considering the quick response in October: https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080513.html while we were still at 10.1-RC1, I wrongly assumed that the problem was noted and will get into the final 10.1. My bad - never *assume*! Mark From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 19:21:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06FEFE35 for ; Wed, 19 Nov 2014 19:21:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D10D7780 for ; Wed, 19 Nov 2014 19:21:17 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A25EFB93E; Wed, 19 Nov 2014 14:21:16 -0500 (EST) From: John Baldwin To: Andreas Nilsson Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles Date: Wed, 19 Nov 2014 14:05:16 -0500 Message-ID: <3870083.h75yLjv6As@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-PRERELEASE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Nov 2014 14:21:16 -0500 (EST) Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:21:18 -0000 On Wednesday, November 19, 2014 05:02:49 PM Andreas Nilsson wrote: > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson wrote: > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky wrote: > >> Daniel, > >> > >> nice to see you here too ;) > >> > >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson wrote: > >> > > unclear is the word for it :) And thanks for looking into this. > >> > >> ipmi/ilo is > >> > >> > > important on a server os. > >> > >> > > I found a reference to it in a ML post: > >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.ht > >> ml > >> > >> > I started that thread :) > >> > I did get it working on the hardware I was using (Supermicro X9SCL-F > >> > >> and X8SIL-F) > >> > >> > I used the following BIOS settings > >> > > >> > ? Remote Access - Enabled > >> > ? Serial Port Number - COM3 > >> > ? Serial Port Mode - 115200, 8, n, 1 > >> > ? Flow Control - Hardware > >> > ? Redirection After BIOS POST - Always > >> > ? Terminal Type - VT100 > >> > ? VT-UTF8 Combo Key Support - Disabled > >> > ? Sredir Memory Display Delay - No Delay > >> > > >> > And the following in loader.conf > >> > # Give preference to VGA console > >> > console="vidconsole,comconsole" > >> > # Uncomment below and comment above to give serial console preference > >> > #console="comconsole,vidconsole" > >> > comconsole_speed="115200" > >> > boot_multicons="YES" > >> > hint.uart.0.flags="0x0" > >> > hint.uart.2.at="isa" > >> > hint.uart.2.port="0x3E8" > >> > hint.uart.2.flags="0x30" > >> > > >> > And this in /etc/ttys > >> > # IPMI console > >> > # Note: The Java console viewer doesn't seem to be very smart as it > >> > >> doesn't > >> > >> > # properly support VT100 > >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on secure > >> > > >> > I could then access it using ipmitool like so > >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > >> > [login] > >> > export TERM=xterm > >> > > >> > Note that I wanted vidconsole by default because mostly the systems > >> > >> were used by people local to them, however we could break into the loader > >> and type 'set console=comconsole,vidconsole? and then get everything over > >> the serial console for remote trouble shooting. > >> > >> > You may also wish to check the IPMI configuration via the web interface > >> > >> - by default it will failover to port 0 and it has terrible default > >> passwords. I changed the passwords and forced it to use the dedicated > >> IPMI > >> port even if nothing was connected to it. > >> > >> Well, I'm almost done with most of our SM server, even concentrated > >> console on > >> our console server with such a simple config: > >> > >> ---- 8< ---- > >> # ipmi/sol console template > >> default ipmi { > >> > >> master localhost; > >> type exec; > >> exec /usr/local/bin/ipmitool -f /usr/local/etc/ipmi-pass -U > >> > >> root -I lanplus -H %.int sol activate; > >> > >> execsubst %=cs; > >> #idletimeout 6h; > >> > >> break 0 { string "~B"; } > >> > >> } > >> > >> console gwn1 { include ipmi; } > >> console gwn2 { include ipmi; } > >> console gwn3 { include ipmi; } > >> console gwn4 { include ipmi; } > >> console gwn5 { include ipmi; } > >> console gwn6 { include ipmi; } > >> console gwn7 { include ipmi; } > >> console gwn8 { include ipmi; } > >> > >> console gwc2 { include ipmi; } > >> ---- 8< ---- > >> > >> This has console logging (including possible panics) as a surplus > >> > >> -- > >> Sincerely, > >> D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > >> [ FreeBSD committer: marck@FreeBSD.org ] > >> ------------------------------------------------------------------------ > >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > >> ------------------------------------------------------------------------ > > > > Hello again, > > > > Searching on hw.uart.console, I found: > > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > > , a very enlightening thread. > > > > Basically: "ohh, you want to use something other than COM1 and tried to > > get away with just changing hint.uart stuff, which has worked for a while, > > ha, no way..." No heads up, nothing. > > > > Sorry to say jhb@ but is not a rare case. It is if not the default, a > > very common setup on every HP server with iLO, and it holds for most all > > OOB style serial emulation I have ever had the (dis)pleasure of working > > with. This was done _specifically_ so you could use non-COM1 for both loader and kernel with one thing to change. That is, you don't use hint.uart.X.flags after this. I have used this with many SuperMicro servers that use COM2 and COM3 because I wanted the entire path (boot loader and kernel) to work, not the kernel only. Having only the kernel means I can't break into the loader prompt to boot a different kernel, single user, etc. To clarify, are you using _different_ serial ports for the loader vs the kernel? That is the use case I considered to be rare. Every single server I have ever worked with (though not iLO, mostly Dell and SuperMicro) uses the same COM port for serial redirection rather for SOL or via actual cables. I've yet to use a system that, for example, used COM1 for the loader and COM2 for the kernel. You are saying that every HP server uses COM1 for the loader and COM2 for the kernel? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 19:37:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27071EC4 for ; Wed, 19 Nov 2014 19:37:22 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B18EC93A for ; Wed, 19 Nov 2014 19:37:21 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id sAJJbI1e072701 for ; Wed, 19 Nov 2014 20:37:18 +0100 (CET) Received: from [217.29.46.116] ([217.29.46.116]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id sAJJbHlh084650 for ; Wed, 19 Nov 2014 20:37:18 +0100 (CET) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: 10.1 geom "diskid" From: "Patrick M. Hausen" In-Reply-To: Date: Wed, 19 Nov 2014 20:37:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D2652B9-0537-4FA4-93F0-4785BE36F066@punkt.de> References: <166BD891-B686-41F9-A741-9C7E7D989CB8@punkt.de> To: "freebsd-stable@freebsd.org List" X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 19:37:22 -0000 Hi, all, > Am 19.11.2014 um 17:46 schrieb Freddie Cash : > Why the gnop acrobatics? >=20 > =E2=80=8BFuture-proofing the pool. :) Precisely. Thanks, Freddie ;) Thanks to everybody else who answered, everything's running smoothely and consistently now: root@seleniumhub:~ # zpool status pool: ssd state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Wed Nov 19 21:16:53 = 2014 config: NAME STATE READ WRITE CKSUM ssd ONLINE 0 0 0 gpt/ssd ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scan: scrub repaired 0 in 0h1m with 0 errors on Wed Nov 19 21:18:05 = 2014 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 logs gpt/zil ONLINE 0 0 0 cache gpt/l2arc ONLINE 0 0 0 errors: No known data errors root@seleniumhub:~ # zdb | grep ashift ashift: 12 ashift: 12 ashift: 12 I did use a 64k offset and 64k boot partitions for zroot this time, so I = did not need to reinstall, just move devices around. I will internally document the = 1M recommendation, though. Used that for the SSD. Possibly vfs.zfs.min_auto_ashift=3D12 should be the default? And the = installer could use some changes for 10.2 in that regard ;) Kind regards Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=C3=BCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 19 22:15:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CD5E582; Wed, 19 Nov 2014 22:15:08 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9ED8DDF6; Wed, 19 Nov 2014 22:15:07 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hz20so1366725lab.34 for ; Wed, 19 Nov 2014 14:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ivbgx+ZC0LED4idJVKXuOvJtDLukpnN/yy/aKyWyHus=; b=BH2fWoHolYI+rYJRDLijQE5F5WdTzcjjino8Fc2YGjTOOqI7PIbM5YG6FRv9W9Uvcw /vI2cYVTlpeQmFmILYxyBTujojlwDB84v7DmqGiX/5O7Lh+5k6fqYSHxZXrNUDmR/JrZ X8qyHZpMtY2ancIzTid+bpK1igRiXaNo1ZoSQoGzDNc2XTxRCRxkm6i98cQcIlG9M8/8 dw+JgiZ9uoAOi35RtBpjOs4HRPzAV5pwNnQ4tkAARZ2EeynSvy0tuWaIbChx8HNqMLkA LeCrqY7i+CLRek4i550j8ylsGt7mfAFy5Ez/0/vp4jyyDB0DgAR9o/weRAORhcP9yj1y fFNg== MIME-Version: 1.0 X-Received: by 10.112.130.132 with SMTP id oe4mr4474294lbb.82.1416435305611; Wed, 19 Nov 2014 14:15:05 -0800 (PST) Received: by 10.25.170.66 with HTTP; Wed, 19 Nov 2014 14:15:05 -0800 (PST) In-Reply-To: <3870083.h75yLjv6As@ralph.baldwin.cx> References: <3870083.h75yLjv6As@ralph.baldwin.cx> Date: Wed, 19 Nov 2014 23:15:05 +0100 Message-ID: Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles From: Andreas Nilsson To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Nov 2014 22:15:08 -0000 On Wed, Nov 19, 2014 at 8:05 PM, John Baldwin wrote: > On Wednesday, November 19, 2014 05:02:49 PM Andreas Nilsson wrote: > > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson > wrote: > > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky > wrote: > > >> Daniel, > > >> > > >> nice to see you here too ;) > > >> > > >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: > > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson > wrote: > > >> > > unclear is the word for it :) And thanks for looking into this. > > >> > > >> ipmi/ilo is > > >> > > >> > > important on a server os. > > >> > > >> > > I found a reference to it in a ML post: > > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.ht > > >> ml > > >> > > >> > I started that thread :) > > >> > I did get it working on the hardware I was using (Supermicro X9SCL-F > > >> > > >> and X8SIL-F) > > >> > > >> > I used the following BIOS settings > > >> > > > >> > ? Remote Access - Enabled > > >> > ? Serial Port Number - COM3 > > >> > ? Serial Port Mode - 115200, 8, n, 1 > > >> > ? Flow Control - Hardware > > >> > ? Redirection After BIOS POST - Always > > >> > ? Terminal Type - VT100 > > >> > ? VT-UTF8 Combo Key Support - Disabled > > >> > ? Sredir Memory Display Delay - No Delay > > >> > > > >> > And the following in loader.conf > > >> > # Give preference to VGA console > > >> > console="vidconsole,comconsole" > > >> > # Uncomment below and comment above to give serial console > preference > > >> > #console="comconsole,vidconsole" > > >> > comconsole_speed="115200" > > >> > boot_multicons="YES" > > >> > hint.uart.0.flags="0x0" > > >> > hint.uart.2.at="isa" > > >> > hint.uart.2.port="0x3E8" > > >> > hint.uart.2.flags="0x30" > > >> > > > >> > And this in /etc/ttys > > >> > # IPMI console > > >> > # Note: The Java console viewer doesn't seem to be very smart as it > > >> > > >> doesn't > > >> > > >> > # properly support VT100 > > >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on secure > > >> > > > >> > I could then access it using ipmitool like so > > >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > >> > [login] > > >> > export TERM=xterm > > >> > > > >> > Note that I wanted vidconsole by default because mostly the systems > > >> > > >> were used by people local to them, however we could break into the > loader > > >> and type 'set console=comconsole,vidconsole? and then get everything > over > > >> the serial console for remote trouble shooting. > > >> > > >> > You may also wish to check the IPMI configuration via the web > interface > > >> > > >> - by default it will failover to port 0 and it has terrible default > > >> passwords. I changed the passwords and forced it to use the dedicated > > >> IPMI > > >> port even if nothing was connected to it. > > >> > > >> Well, I'm almost done with most of our SM server, even concentrated > > >> console on > > >> our console server with such a simple config: > > >> > > >> ---- 8< ---- > > >> # ipmi/sol console template > > >> default ipmi { > > >> > > >> master localhost; > > >> type exec; > > >> exec /usr/local/bin/ipmitool -f /usr/local/etc/ipmi-pass -U > > >> > > >> root -I lanplus -H %.int sol activate; > > >> > > >> execsubst %=cs; > > >> #idletimeout 6h; > > >> > > >> break 0 { string "~B"; } > > >> > > >> } > > >> > > >> console gwn1 { include ipmi; } > > >> console gwn2 { include ipmi; } > > >> console gwn3 { include ipmi; } > > >> console gwn4 { include ipmi; } > > >> console gwn5 { include ipmi; } > > >> console gwn6 { include ipmi; } > > >> console gwn7 { include ipmi; } > > >> console gwn8 { include ipmi; } > > >> > > >> console gwc2 { include ipmi; } > > >> ---- 8< ---- > > >> > > >> This has console logging (including possible panics) as a surplus > > >> > > >> -- > > >> Sincerely, > > >> D.Marck [DM5020, MCK-RIPE, > DM3-RIPN] > > >> [ FreeBSD committer: marck@FreeBSD.org > ] > > >> > ------------------------------------------------------------------------ > > >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru > *** > > >> > ------------------------------------------------------------------------ > > > > > > Hello again, > > > > > > Searching on hw.uart.console, I found: > > > > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > > > , a very enlightening thread. > > > > > > Basically: "ohh, you want to use something other than COM1 and tried to > > > get away with just changing hint.uart stuff, which has worked for a > while, > > > ha, no way..." No heads up, nothing. > > > > > > Sorry to say jhb@ but is not a rare case. It is if not the default, a > > > very common setup on every HP server with iLO, and it holds for most > all > > > OOB style serial emulation I have ever had the (dis)pleasure of working > > > with. > > This was done _specifically_ so you could use non-COM1 for both loader and > kernel with one thing to change. That is, you don't use hint.uart.X.flags > after this. I have used this with many SuperMicro servers that use COM2 > and > COM3 because I wanted the entire path (boot loader and kernel) to work, not > the kernel only. Having only the kernel means I can't break into the > loader > prompt to boot a different kernel, single user, etc. > > To clarify, are you using _different_ serial ports for the loader vs the > kernel? That is the use case I considered to be rare. Every single server > I have ever worked with (though not iLO, mostly Dell and SuperMicro) uses > the > same COM port for serial redirection rather for SOL or via actual cables. > I've yet to use a system that, for example, used COM1 for the loader and > COM2 > for the kernel. You are saying that every HP server uses COM1 for the > loader > and COM2 for the kernel? > > -- > John Baldwin > Hello, For Supermicro: The box was in a rack when I started this, so I don't really know how the bios is setup, but as far as I can gather, getting "BTX loader yadda yadda" seems to always happen, on any COM-port. The actual output from loading modules and so on only happens with specific settings. Here ( as in an answer to Dmitry I accidentally sent in private ) things seems to be on different COMs: Setting: comconsole_port=0x2F8 (com2) show loader and goes dark on handoff to kernel comconsole_port=0x3E8 (com3) show no loader and stays dark Neither of them gives me console even after successful boot. The only way to get serial is setting hw.uart.console="br:9600" explicitly. For HP I asked a colleague, and we couldn't exactly remember ( it was quite a while since these boxes were deployed ), but our recollection was that serial setup was left as-is, which seems to be that "vsp" from iLO gives you a tty on 0x2F8. Setting that in comconsole_port in loader.conf works. Both In an effort of standardising stuff, we put hw-dependent stuff in loader.conf, ie hint.uart redirection to have the same entry in the ttys file. Having serial over ipmi/ilo go dark during remote upgrades is scary at best. Seeing that this change has such a potential, how come it is not mentioned in the release notes? Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 07:43:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 839FA2B4 for ; Thu, 20 Nov 2014 07:43:20 +0000 (UTC) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48A18D33 for ; Thu, 20 Nov 2014 07:43:20 +0000 (UTC) Received: from hexe.rlwinm.de (p57A7C627.dip0.t-ipconnect.de [87.167.198.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 5C248C5CD for ; Thu, 20 Nov 2014 08:43:16 +0100 (CET) Message-ID: <546D9B93.5010003@rlwinm.de> Date: Thu, 20 Nov 2014 08:43:15 +0100 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 07:43:20 -0000 On 11.11.2014 18:30, Dmitry Morozovsky wrote: > Dear colleagues, > > I'm trying to set up sol console for supermicro servers, reading some documents > including TestClusterOne, mainly: > >> For serial redirection to work, in the BIOS you need to redirect to com port >> B and in /boot/device.hints you need hint.uart.1.flags="0x10" and enable getty on >> cuau1 > > I can see BIOS screen ok; boot1/2 and boot/loader work fine also. However, I > could not see kernel console output via SOL, neither getty on ttyu1 works. > I tried different speeds, std vs 3wire, explicitely set console=comconsole > vidconsole -- no luck. > > I even trued to use `ipmitool sol activate' on one side and `tip -115200 com2' > on the other -- stiil no data between. > > Any hints? Here is my configuration for SuperMicro boards: # loader.conf console="comconsole vidconsole" comconsole_speed="115200" comconsole_port="0x2F8" boot_multicons="YES" # /etc/ttys ttyu1 "/usr/libexec/getty std.115200" vt100 on secure Depending on your Board the IPMI SoL is either COM2 oder COM3 by default. My config snippets assume COM2 (0x2F8). If you board still has two physical COM ports the IPMI SoL moves to COM3 (0x3E8) and ttyu2. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 10:24:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCA0C64B for ; Thu, 20 Nov 2014 10:24:05 +0000 (UTC) Received: from kaija.ugh.net.au (kaija.ugh.net.au [IPv6:2a00:1a48:7803:107:65bc:4bde:ff08:1f7f]) by mx1.freebsd.org (Postfix) with ESMTP id 979DF1C9 for ; Thu, 20 Nov 2014 10:24:05 +0000 (UTC) Received: from [IPv6:2a00:c1a0:c100:2700:61b3:edb9:4235:ba65] (unknown [IPv6:2a00:c1a0:c100:2700:61b3:edb9:4235:ba65]) by kaija.ugh.net.au (Postfix) with ESMTPSA id 9D8309751 for ; Thu, 20 Nov 2014 10:24:02 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: build world failing From: Andrew Stevenson In-Reply-To: <5D131B1C-A13A-45F0-97A4-976FDEE8B59A@ugh.net.au> Date: Thu, 20 Nov 2014 11:23:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C0C65F2-558B-4759-BE6C-BB4668C0E681@ugh.net.au> <0120C440-95F1-4183-9AD4-2CA1B35E713A@ugh.net.au> <4D71855F-1F3E-4AED-A214-8D7F431E373E@FreeBSD.org> <5D131B1C-A13A-45F0-97A4-976FDEE8B59A@ugh.net.au> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 10:24:05 -0000 On 16 Nov 2014, at 18:02, Andrew Stevenson wrote: > I=92m trying to build clang with CFLAGS=3D-O0 now. In an hour or two = I=92ll see if it helps! More like a day or two! It really shows how much compiler optimisation = helps. build world finished successfully when building with -O0. Of course now = I have an entire unoptimised world=85 I will (once the kernel is done) try running this and use it as a base = for an attempt with -O1. Thanks, Andrew= From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 12:23:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278355F2 for ; Thu, 20 Nov 2014 12:23:59 +0000 (UTC) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0C7F91 for ; Thu, 20 Nov 2014 12:23:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1416486231; bh=G/W9t1oJFhCCyqS2HL7dt7TMyf4pN4SQXQ40Rr5k5/o=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=abwN92lPovMC5Nad1usc7pVJ0qpezJ2Pi11VjCK/T3eCL4hQq7BPkY0GO0eA4RnTA3zb9Pu/D1o15kGyoayBC2uU28UZuXkALS5nAiYaWJbF8iod/h94LCeVH62SYdzh+e4Nbg3mKpHk9TUNSbYuuYpdsZP6dlW8mbDpSFnKl7dhcyQdupazuP5pjuiAr9MTwvP+ZYP+1gIatAHEijvot2GxpTRJX1R5Sb78lIuI5ghGEzGImMtjDppq7QJMRasopF+ydjWTWCHfSaLISrad1IDGpaPcjlKVLvGatKj243goV9DYywmoSHO1kzfxLkf2Kh9h00wYzFIqGApdKXqWAA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=JRzI0/bB0JhPazq9CWcS8gW1V+iaXdYMmVDJHdjz0s5eJ4s4JDZR6mdkdFvAcGaQDnr5QWQY/cclUqlxMhSBNWpRLFobtTaZWl4ynwYUirWanRg559f9ORTb93hgmG91OndabEQyHi33jviarRGCrjQ+FHbF2SkhkE/EaczBw7YELRUoSncKNQt/vjCVMzyjwiOsNq98H6AkhMN6IwQhikKiVprLdfcqjciKlfhHSYb2C8NE5rJKZNh5LnQIx9Jw5JaX5TDEhtuYJ4cL99lV9ZdsfW3XuVYVrIzfB2VzcXUBu/itRChwiHstB2znBrNErfFnAJJThT4cnNU5AfNrmA==; Received: from [98.139.212.153] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2014 12:23:51 -0000 Received: from [98.139.213.14] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 20 Nov 2014 12:23:50 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 20 Nov 2014 12:23:50 -0000 X-Yahoo-Newman-Id: 941390.45704.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: n7adjHMVM1k3dryd0feACW41URosRA.QzVggVpzTPrscFx4 zGj5CGo2hQ446XoPNrpGs8UE_YhQF14h7hjCTp0FfVBnFSxu5E.e7GOwrKOR DwMzd_m3zYEYNtphuSoS7HVCYb3c3BQ2CP_MGQpkOoDMyrKZcL9JKfU7zPVy P4cFlw1HLZm3aOkrT8xTr6MNLn4HvuZI2.8MrBSC.97WzCkcFt99vZQaHPmf 3Te6sxUOeRicFNBgFLIHLugdZWsDVe6rn46KSv03CVBu8C6BzL_TNkIo_Squ KiY6PcIaAeu4Mb4Lv4kK48G1U_Cx3hbZZruvh5D6vM3ZgAIDy0XpI7bxC464 uFlAcZOIL2hUSVVK1yfHFrq_vVjdZFVFlQVpOmoeBw0Q0rsV3g.VTJIDcm.F oTxjjFPgHXaNdFACQMPEmHAd.w.eJD_4Lx749Z2gWE9DonpFsHCrRN4qYjzJ c4ze5.Q7n31LrMvY42ICUXZkKEu6mmcsVc8xUMKiln7aRsfwJTD4E3dzaxju TyL9C6jMMX_loOzW2epc.ONWrYGVbrRJad5Q- X-Yahoo-SMTP: 6IZaPQyswBAeyzp3urHRlQfBxGxx4Js3YAIn Message-ID: <546DDD8E.2090606@yahoo.com> Date: Thu, 20 Nov 2014 04:24:46 -0800 From: Jeffrey Bouquet User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org, freebsd-pkg@freebsd.org, freebsd-stable@freebsd.org Subject: Re: pkg problem References: <546DDC67.3080409@yahoo.com> In-Reply-To: <546DDC67.3080409@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 12:23:59 -0000 On 11/20/14 04:19, Jeffrey Bouquet wrote: > Only one port has not failed at "pkg install port" ... after today's > update and > also failed at deinstall pkg >> install pkg-devel to try to fix it. > > [ Duplicate post, so I could post the error and this update. ] > > > Script started on Thu Nov 20 04:09:36 2014 > > > pkg --version > 1.4.0.beta2 # pkg-devel newly installed, did not fix the below. > > pkg install tk86 > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > > Checking integrity...Assertion failed: (pkgdb_ensure_loaded(j->db, p2, > PKG_LOAD_FILES|PKG_LOAD_DIRS) == EPKG_OK), function > pkg_conflicts_need_conflict, file pkg_jobs_conflicts.c, line 211. Child > process pid=41497 terminated abnormally: Abort trap: 6 > > > Script done on Thu Nov 20 04:10:25 2014 From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 13:04:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93C7AF0E; Thu, 20 Nov 2014 13:04:00 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2029B69F; Thu, 20 Nov 2014 13:04:00 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so3670650wgg.29 for ; Thu, 20 Nov 2014 05:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RQC7LvjMv3q137W/AanPuS0u3nm8YUBDClYDhNfyvVU=; b=I92Rt5B3VhZkHSIYelc/il69eo+R+ZW7VV8TZwpcNBAK5+j96dkaDkTyMavUeUpUc+ kzfywUThnIREpHrFHwE88GmiXGr+zVe/5Xc5hfJVZ0Y75ekZF9B6fVopnWjJCWYE3Ni6 E7rNpwCQw7HbAMYx/7EoSOL+ZAbRTKYVTWJddGCZQJIkMp5Qwj6NAlMowFV/bOl2h5c9 Ev1RA6GZbnui06TO7GaZh3KLp5kZPjojzyV9JMwm/Opr1amzuz6IsEjMfwk9aRNhIvNM RpfTRFynAe0As/kPt62I8+aiaaYY/MRHqBqtvtyuznxC7ONXH+ekO+lsAxp/1gVfJRXe XeKQ== X-Received: by 10.194.158.193 with SMTP id ww1mr69113643wjb.65.1416488638478; Thu, 20 Nov 2014 05:03:58 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id f7sm3995571wiz.13.2014.11.20.05.03.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Nov 2014 05:03:57 -0800 (PST) Sender: Baptiste Daroussin Date: Thu, 20 Nov 2014 14:03:55 +0100 From: Baptiste Daroussin To: Jeffrey Bouquet Subject: Re: pkg problem Message-ID: <20141120130355.GW48896@ivaldir.etoilebsd.net> References: <546DDC67.3080409@yahoo.com> <546DDD8E.2090606@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m9FEOsnejx470nED" Content-Disposition: inline In-Reply-To: <546DDD8E.2090606@yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 13:04:00 -0000 --m9FEOsnejx470nED Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 20, 2014 at 04:24:46AM -0800, Jeffrey Bouquet via freebsd-stabl= e wrote: >=20 > On 11/20/14 04:19, Jeffrey Bouquet wrote: > > Only one port has not failed at "pkg install port" ... after today's > > update and > > also failed at deinstall pkg >> install pkg-devel to try to fix it. > > > > [ Duplicate post, so I could post the error and this update. ] > > > > > > Script started on Thu Nov 20 04:09:36 2014 > > > > > > pkg --version > > 1.4.0.beta2 # pkg-devel newly installed, did not fix the below. > > > > pkg install tk86 > > Updating FreeBSD repository catalogue... > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > > > Checking integrity...Assertion failed: (pkgdb_ensure_loaded(j->db, p2, > > PKG_LOAD_FILES|PKG_LOAD_DIRS) =3D=3D EPKG_OK), function > > pkg_conflicts_need_conflict, file pkg_jobs_conflicts.c, line 211. Child > > process pid=3D41497 terminated abnormally: Abort trap: 6 > > > > > > Script done on Thu Nov 20 04:10:25 2014 Is that with pkg.freebsd.org repository, or custom one? regards, Bapt --m9FEOsnejx470nED Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRt5rsACgkQ8kTtMUmk6EyXXACfUUgQo+Yx8i7ZkCISRfvG/Jmb wN0AoKAIa9ErKcF1e6HvyUhPAar3i3LR =OpjV -----END PGP SIGNATURE----- --m9FEOsnejx470nED-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 17:06:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AC5E630; Thu, 20 Nov 2014 17:06:12 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1F1D885; Thu, 20 Nov 2014 17:06:11 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKH78gS071061; Thu, 20 Nov 2014 09:07:08 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD STABLE" , "FreeBSD CURRENT" From: "Chris H" Subject: send-pr must live Date: Thu, 20 Nov 2014 09:07:08 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:06:12 -0000 Greetings, While I recognize that send-pr has pretty much become useless, with the advent of bugzilla, being made the new "official" FreeBSD bug reporting system. I really miss send-pr, and was hoping I could revive it, eg; integrate it with bugzilla. I had even contemplated adding a feature that would allow it to also work with local port/system building structures people often use to build, and maintain FreeBSD. Any objections to my reviving send-pr? Thank you for all your time, and consideration. --Chris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 17:25:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 870C114A; Thu, 20 Nov 2014 17:25:51 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49254B69; Thu, 20 Nov 2014 17:25:51 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wp4so2566793obc.39 for ; Thu, 20 Nov 2014 09:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EygNMTTfIMilhMwDjnDg4usPlC8VZ1/UbzjwK45FDJ4=; b=PmtBR1pZKGlC2FyjZA4AIJta8N7aNBUYDFwM4H3rvXVzVlpivIEb/wVwCnui8Ba+ig z/ZQjDGEea7EwolOGU2JWhF/pKGgUFLIiyMUuy2GudOZknbRMeVEiqjGtypaKRuJfh2b 8pb/Jt5MOceIwsyGdyynHanriX7vuw/PM5YD72ySy5jbFHBb/mTy4K4dUjX9HoxWAQDm drPAWFSHMWwqEO0IoX7SXkXqVtb3btUuKRj6lq2GVkHQ7Za/fYmR6B9NFKnD109+KF6i TvSclV5za+Otl/BUeHXADuBx5eXeQbBmOzBZfdxrRMZWH9f7ZW3bpoIVnDF/FVNYUci/ mxfw== MIME-Version: 1.0 X-Received: by 10.60.161.115 with SMTP id xr19mr42541085oeb.8.1416504350626; Thu, 20 Nov 2014 09:25:50 -0800 (PST) Received: by 10.202.59.133 with HTTP; Thu, 20 Nov 2014 09:25:50 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Nov 2014 23:25:50 +0600 Message-ID: Subject: Re: send-pr must live From: Muhammad Moinur Rahman <5u623l20@gmail.com> To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:25:51 -0000 Nice idea. However I am working on reviving porttools to migrate within bugzilla system. Maybe we can share some ideas. BR, Muhammad On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: > Greetings, > While I recognize that send-pr has pretty much > become useless, with the advent of bugzilla, being made > the new "official" FreeBSD bug reporting system. I really > miss send-pr, and was hoping I could revive it, eg; > integrate it with bugzilla. I had even contemplated adding > a feature that would allow it to also work with local > port/system building structures people often use to build, > and maintain FreeBSD. > Any objections to my reviving send-pr? > > Thank you for all your time, and consideration. > > --Chris > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 17:39:55 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD5609EC; Thu, 20 Nov 2014 17:39:55 +0000 (UTC) Received: from gwave1.banym.de (gwave1.banym.de [212.72.74.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90724CED; Thu, 20 Nov 2014 17:39:55 +0000 (UTC) Received: from tesla.banym.local (dslb-084-057-003-046.084.057.pools.vodafone-ip.de [84.57.3.46]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by gwave1.banym.de (Postfix) with ESMTP id 3A8A41C003; Thu, 20 Nov 2014 18:39:18 +0100 (CET) Message-ID: <546E2752.3060609@banym.de> Date: Thu, 20 Nov 2014 18:39:30 +0100 From: Dominik Zajac User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: UEFI Boot fails if legacy mode is disabled completely in settings on ASUS Z87 board Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Banym-MailScanner-Information: Please contact the ISP for more information X-Banym-MailScanner-ID: 3A8A41C003.A327C X-Banym-MailScanner: Found to be clean X-Banym-MailScanner-From: banym@banym.de X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:39:55 -0000 Hi, on an ASUS Z87 Pro board, the UEFI boot media only work if the CSM mode in the Settings of the UEFI are set to "both". This means it is using UEFI boot and CSM mode for legacy booting. If I disable the legacy CSM and configure "UEFI only", the UEFI loader still loads but when it comes to load the kernel it just stops and the system is frozen at that point. Same with 10.1 and 11-current USB install media. The system now has FreeBSD 10.1 on one disc installed with UEFI mode and boots with it as long as the CSM compatibility mode is enabled. Has someone a similar problem or behaviour? This leads me to the next question. How can I debug or get more information what fails at this stage of the boot process? I would like to provide more detailed information and help to debug to hunt this bug down. Regards, Dominik From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 17:39:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E029B9EB; Thu, 20 Nov 2014 17:39:54 +0000 (UTC) Received: from mx.waitman.net (mx.waitman.net [136.0.16.173]) by mx1.freebsd.org (Postfix) with ESMTP id C7CA4CEC; Thu, 20 Nov 2014 17:39:54 +0000 (UTC) Received: by mx.waitman.net (Postfix, from userid 2) id 509ED435B6; Thu, 20 Nov 2014 09:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waitman.net; s=default; t=1416505216; bh=fno9McsvKYOX20BlnMd4YxNMDIpEMIfDS5T9tUfat3M=; h=In-Reply-To:References:Date:Subject:From:To:Cc:Reply-To; b=F6cjN4u0ljQ+QVyA0Uu6nTDbskH1HRNY7Aq/hkHi8B70pD7tBRzl4sasquIPUp771 hf9CwazOl2yhqVXHMnIX9emmxxIfHSxdzMlYj0szZCyyVdvJulZan4svN7xvQsj7k1 qvl99XzOtLPxzagkY9v54GA8QJZeQazvKJfzEAMc= Received: from 70.90.171.37 by mx.waitman.net with HTTP; Thu, 20 Nov 2014 09:40:16 -0800 Message-ID: In-Reply-To: References: Date: Thu, 20 Nov 2014 09:40:16 -0800 Subject: Re: send-pr must live From: "Waitman Gobble" To: "Muhammad Moinur Rahman" <5u623l20@gmail.com> Reply-To: waitman@waitman.net User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT , Chris H X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:39:55 -0000 On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: > Nice idea. However I am working on reviving porttools to migrate within > bugzilla system. Maybe we can share some ideas. > > BR, > Muhammad > > > On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: > > >> Greetings, >> While I recognize that send-pr has pretty much >> become useless, with the advent of bugzilla, being made the new >> "official" FreeBSD bug reporting system. I really >> miss send-pr, and was hoping I could revive it, eg; integrate it with >> bugzilla. I had even contemplated adding a feature that would allow it >> to also work with local port/system building structures people often use >> to build, and maintain FreeBSD. Any objections to my reviving send-pr? >> >> >> Thank you for all your time, and consideration. >> >> >> --Chris >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST API but current versions use plugin. Also I believe Bugzilla supports an email interface so it could be possible to keep send-pr as a shell script. -- Waitman Gobble Los Altos California USA +1.510-830-7975 From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 17:57:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B97D84DD for ; Thu, 20 Nov 2014 17:57:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FCE2F19 for ; Thu, 20 Nov 2014 17:57:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 810F3B984; Thu, 20 Nov 2014 12:57:15 -0500 (EST) From: John Baldwin To: Andreas Nilsson Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles Date: Thu, 20 Nov 2014 11:45:00 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <3870083.h75yLjv6As@ralph.baldwin.cx> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201411201145.01162.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 20 Nov 2014 12:57:15 -0500 (EST) Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 17:57:16 -0000 On Wednesday, November 19, 2014 5:15:05 pm Andreas Nilsson wrote: > On Wed, Nov 19, 2014 at 8:05 PM, John Baldwin wrote: > > > On Wednesday, November 19, 2014 05:02:49 PM Andreas Nilsson wrote: > > > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson > > wrote: > > > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky > > wrote: > > > >> Daniel, > > > >> > > > >> nice to see you here too ;) > > > >> > > > >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: > > > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson > > wrote: > > > >> > > unclear is the word for it :) And thanks for looking into this. > > > >> > > > >> ipmi/ilo is > > > >> > > > >> > > important on a server os. > > > >> > > > >> > > I found a reference to it in a ML post: > > > >> > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.ht > > > >> ml > > > >> > > > >> > I started that thread :) > > > >> > I did get it working on the hardware I was using (Supermicro X9SCL- F > > > >> > > > >> and X8SIL-F) > > > >> > > > >> > I used the following BIOS settings > > > >> > > > > >> > ? Remote Access - Enabled > > > >> > ? Serial Port Number - COM3 > > > >> > ? Serial Port Mode - 115200, 8, n, 1 > > > >> > ? Flow Control - Hardware > > > >> > ? Redirection After BIOS POST - Always > > > >> > ? Terminal Type - VT100 > > > >> > ? VT-UTF8 Combo Key Support - Disabled > > > >> > ? Sredir Memory Display Delay - No Delay > > > >> > > > > >> > And the following in loader.conf > > > >> > # Give preference to VGA console > > > >> > console="vidconsole,comconsole" > > > >> > # Uncomment below and comment above to give serial console > > preference > > > >> > #console="comconsole,vidconsole" > > > >> > comconsole_speed="115200" > > > >> > boot_multicons="YES" > > > >> > hint.uart.0.flags="0x0" > > > >> > hint.uart.2.at="isa" > > > >> > hint.uart.2.port="0x3E8" > > > >> > hint.uart.2.flags="0x30" > > > >> > > > > >> > And this in /etc/ttys > > > >> > # IPMI console > > > >> > # Note: The Java console viewer doesn't seem to be very smart as it > > > >> > > > >> doesn't > > > >> > > > >> > # properly support VT100 > > > >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on secure > > > >> > > > > >> > I could then access it using ipmitool like so > > > >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > > >> > [login] > > > >> > export TERM=xterm > > > >> > > > > >> > Note that I wanted vidconsole by default because mostly the systems > > > >> > > > >> were used by people local to them, however we could break into the > > loader > > > >> and type 'set console=comconsole,vidconsole? and then get everything > > over > > > >> the serial console for remote trouble shooting. > > > >> > > > >> > You may also wish to check the IPMI configuration via the web > > interface > > > >> > > > >> - by default it will failover to port 0 and it has terrible default > > > >> passwords. I changed the passwords and forced it to use the dedicated > > > >> IPMI > > > >> port even if nothing was connected to it. > > > >> > > > >> Well, I'm almost done with most of our SM server, even concentrated > > > >> console on > > > >> our console server with such a simple config: > > > >> > > > >> ---- 8< ---- > > > >> # ipmi/sol console template > > > >> default ipmi { > > > >> > > > >> master localhost; > > > >> type exec; > > > >> exec /usr/local/bin/ipmitool -f /usr/local/etc/ipmi-pass - U > > > >> > > > >> root -I lanplus -H %.int sol activate; > > > >> > > > >> execsubst %=cs; > > > >> #idletimeout 6h; > > > >> > > > >> break 0 { string "~B"; } > > > >> > > > >> } > > > >> > > > >> console gwn1 { include ipmi; } > > > >> console gwn2 { include ipmi; } > > > >> console gwn3 { include ipmi; } > > > >> console gwn4 { include ipmi; } > > > >> console gwn5 { include ipmi; } > > > >> console gwn6 { include ipmi; } > > > >> console gwn7 { include ipmi; } > > > >> console gwn8 { include ipmi; } > > > >> > > > >> console gwc2 { include ipmi; } > > > >> ---- 8< ---- > > > >> > > > >> This has console logging (including possible panics) as a surplus > > > >> > > > >> -- > > > >> Sincerely, > > > >> D.Marck [DM5020, MCK-RIPE, > > DM3-RIPN] > > > >> [ FreeBSD committer: marck@FreeBSD.org > > ] > > > >> > > ------------------------------------------------------------------------ > > > >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru > > *** > > > >> > > ------------------------------------------------------------------------ > > > > > > > > Hello again, > > > > > > > > Searching on hw.uart.console, I found: > > > > > > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > > > > , a very enlightening thread. > > > > > > > > Basically: "ohh, you want to use something other than COM1 and tried to > > > > get away with just changing hint.uart stuff, which has worked for a > > while, > > > > ha, no way..." No heads up, nothing. > > > > > > > > Sorry to say jhb@ but is not a rare case. It is if not the default, a > > > > very common setup on every HP server with iLO, and it holds for most > > all > > > > OOB style serial emulation I have ever had the (dis)pleasure of working > > > > with. > > > > This was done _specifically_ so you could use non-COM1 for both loader and > > kernel with one thing to change. That is, you don't use hint.uart.X.flags > > after this. I have used this with many SuperMicro servers that use COM2 > > and > > COM3 because I wanted the entire path (boot loader and kernel) to work, not > > the kernel only. Having only the kernel means I can't break into the > > loader > > prompt to boot a different kernel, single user, etc. > > > > To clarify, are you using _different_ serial ports for the loader vs the > > kernel? That is the use case I considered to be rare. Every single server > > I have ever worked with (though not iLO, mostly Dell and SuperMicro) uses > > the > > same COM port for serial redirection rather for SOL or via actual cables. > > I've yet to use a system that, for example, used COM1 for the loader and > > COM2 > > for the kernel. You are saying that every HP server uses COM1 for the > > loader > > and COM2 for the kernel? > > > > -- > > John Baldwin > > > > Hello, > > For Supermicro: > The box was in a rack when I started this, so I don't really know how the > bios is setup, but as far as I can gather, getting > "BTX loader yadda yadda" seems to always happen, on any COM-port. > The actual output from loading modules and so on only happens with specific > settings. Here ( as in an answer to Dmitry I accidentally sent in private ) > things seems to be on different COMs: Setting: comconsole_port=0x2F8 (com2) > show loader and goes dark on handoff to kernel > comconsole_port=0x3E8 (com3) show no loader and stays dark > > Neither of them gives me console even after successful boot. The only way > to get serial is setting hw.uart.console="br:9600" explicitly. On the SuperMicro systems I have played with (X8DTU and the X9DRW equivalent), comconsole_port=0x2f8 worked for both BIOS, loader, and kernel, but for BIOS to work I did have to enable Console Redirection in the BIOS. For 2U machines (X8DAH at least, I think also for X9 equivalent), SOL was on COM3 instead of COM2, but using comconsole_port alone worked for BIOS, loader, and kernel. I also set the speed to 115200 (conspeed) which IIRC might have been the default setting in the BIOS when Console Redirection was enabled via SOL. You can check that remotely for SOL via ipmitool by seeing what baud rate it is set to. I think if IPMI expects 115200 and you use 9600, that might explain black output. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 18:09:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FD37BC9; Thu, 20 Nov 2014 18:09:02 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 406D4E4; Thu, 20 Nov 2014 18:09:02 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKI9xbB088551; Thu, 20 Nov 2014 10:09:59 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "Muhammad Moinur Rahman" <5u623l20@gmail.com>, "Waitman Gobble" In-Reply-To: References: , From: "Chris H" Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 10:09:59 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:09:02 -0000 On Thu, 20 Nov 2014 09:40:16 -0800 "Waitman Gobble" wrote > On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: > > Nice idea. However I am working on reviving porttools to migrate within > > bugzilla system. Maybe we can share some ideas. > > > > BR, > > Muhammad > > > > > > On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: > > > > > >> Greetings, > >> While I recognize that send-pr has pretty much > >> become useless, with the advent of bugzilla, being made the new > >> "official" FreeBSD bug reporting system. I really > >> miss send-pr, and was hoping I could revive it, eg; integrate it with > >> bugzilla. I had even contemplated adding a feature that would allow it > >> to also work with local port/system building structures people often use > >> to build, and maintain FreeBSD. Any objections to my reviving send-pr? > >> > >> > >> Thank you for all your time, and consideration. > >> > >> > >> --Chris > >> > >> > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > >> > >> > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST > API but current versions use plugin. Also I believe Bugzilla supports an > email interface so it could be possible to keep send-pr as a shell script. Indeed. It is perfectly inclined to use email. Which makes [initial] integration perfectly *trivial*. :) As to it having been shell based. While there's nothing wrong with that at all, in fact it's advantageous in many respects. I was toying with the idea of perhaps converting (augmenting) it to being Perl based, by way of a statically linked mini-perl interpreter. I thought it would better *empower* it, also providing for a more "user friendly" dialog. But, like I said; just *toying* with the idea. :) --Chris > > > > -- > Waitman Gobble > Los Altos California USA > +1.510-830-7975 From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 18:09:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C208E6A; Thu, 20 Nov 2014 18:09:09 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CF37E6; Thu, 20 Nov 2014 18:09:08 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id mc6so2880767lab.38 for ; Thu, 20 Nov 2014 10:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6mX6TZCTIW3r7loeE4NyCnXZo1IwfkWbIAtwOGiL6Gc=; b=VRS8JCFfJmrihJxKfjYV+zKkyjOvx3wHheHNWQRDjJZOVTodpduioa0MDlo4ljPFHS JeyHwRxjBid5U6EbQBu2pa+e4dEjiP9P/Edwrok1o3BqxAVJFfHtbS3zhHrMtdvSv0Wd MpmdSvSFN9Xg01UVfZhaGbSWjeVWVP6flv/2P6OoAMhWKgQUzZA+L7thT/rE2dBbn6YY pN7B12G0VMPCgo3iAVcQBmk/CT6ShfKXAJPLF1iKA1eLY7ALt+5KUQIHN/V2GgZTya4b BJUYYmXFkBNTgTINq0+1/7+BmDX6ItXcAfGbeZ7TKr2fxRTygrHxRPwW/NSYNcac4Fh8 RXew== MIME-Version: 1.0 X-Received: by 10.112.199.100 with SMTP id jj4mr12908842lbc.71.1416506946319; Thu, 20 Nov 2014 10:09:06 -0800 (PST) Received: by 10.25.170.66 with HTTP; Thu, 20 Nov 2014 10:09:06 -0800 (PST) In-Reply-To: <201411201145.01162.jhb@freebsd.org> References: <3870083.h75yLjv6As@ralph.baldwin.cx> <201411201145.01162.jhb@freebsd.org> Date: Thu, 20 Nov 2014 19:09:06 +0100 Message-ID: Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles From: Andreas Nilsson To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:09:09 -0000 On Thu, Nov 20, 2014 at 5:45 PM, John Baldwin wrote: > On Wednesday, November 19, 2014 5:15:05 pm Andreas Nilsson wrote: > > On Wed, Nov 19, 2014 at 8:05 PM, John Baldwin wrote: > > > > > On Wednesday, November 19, 2014 05:02:49 PM Andreas Nilsson wrote: > > > > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson > > > > wrote: > > > > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky > > > > wrote: > > > > >> Daniel, > > > > >> > > > > >> nice to see you here too ;) > > > > >> > > > > >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: > > > > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson > > > wrote: > > > > >> > > unclear is the word for it :) And thanks for looking into > this. > > > > >> > > > > >> ipmi/ilo is > > > > >> > > > > >> > > important on a server os. > > > > >> > > > > >> > > I found a reference to it in a ML post: > > > > >> > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.ht > > > > >> ml > > > > >> > > > > >> > I started that thread :) > > > > >> > I did get it working on the hardware I was using (Supermicro > X9SCL- > F > > > > >> > > > > >> and X8SIL-F) > > > > >> > > > > >> > I used the following BIOS settings > > > > >> > > > > > >> > ? Remote Access - Enabled > > > > >> > ? Serial Port Number - COM3 > > > > >> > ? Serial Port Mode - 115200, 8, n, 1 > > > > >> > ? Flow Control - Hardware > > > > >> > ? Redirection After BIOS POST - Always > > > > >> > ? Terminal Type - VT100 > > > > >> > ? VT-UTF8 Combo Key Support - Disabled > > > > >> > ? Sredir Memory Display Delay - No Delay > > > > >> > > > > > >> > And the following in loader.conf > > > > >> > # Give preference to VGA console > > > > >> > console="vidconsole,comconsole" > > > > >> > # Uncomment below and comment above to give serial console > > > preference > > > > >> > #console="comconsole,vidconsole" > > > > >> > comconsole_speed="115200" > > > > >> > boot_multicons="YES" > > > > >> > hint.uart.0.flags="0x0" > > > > >> > hint.uart.2.at="isa" > > > > >> > hint.uart.2.port="0x3E8" > > > > >> > hint.uart.2.flags="0x30" > > > > >> > > > > > >> > And this in /etc/ttys > > > > >> > # IPMI console > > > > >> > # Note: The Java console viewer doesn't seem to be very smart > as it > > > > >> > > > > >> doesn't > > > > >> > > > > >> > # properly support VT100 > > > > >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on > secure > > > > >> > > > > > >> > I could then access it using ipmitool like so > > > > >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > > > >> > [login] > > > > >> > export TERM=xterm > > > > >> > > > > > >> > Note that I wanted vidconsole by default because mostly the > systems > > > > >> > > > > >> were used by people local to them, however we could break into the > > > loader > > > > >> and type 'set console=comconsole,vidconsole? and then get > everything > > > over > > > > >> the serial console for remote trouble shooting. > > > > >> > > > > >> > You may also wish to check the IPMI configuration via the web > > > interface > > > > >> > > > > >> - by default it will failover to port 0 and it has terrible > default > > > > >> passwords. I changed the passwords and forced it to use the > dedicated > > > > >> IPMI > > > > >> port even if nothing was connected to it. > > > > >> > > > > >> Well, I'm almost done with most of our SM server, even > concentrated > > > > >> console on > > > > >> our console server with such a simple config: > > > > >> > > > > >> ---- 8< ---- > > > > >> # ipmi/sol console template > > > > >> default ipmi { > > > > >> > > > > >> master localhost; > > > > >> type exec; > > > > >> exec /usr/local/bin/ipmitool -f > /usr/local/etc/ipmi-pass - > U > > > > >> > > > > >> root -I lanplus -H %.int sol activate; > > > > >> > > > > >> execsubst %=cs; > > > > >> #idletimeout 6h; > > > > >> > > > > >> break 0 { string "~B"; } > > > > >> > > > > >> } > > > > >> > > > > >> console gwn1 { include ipmi; } > > > > >> console gwn2 { include ipmi; } > > > > >> console gwn3 { include ipmi; } > > > > >> console gwn4 { include ipmi; } > > > > >> console gwn5 { include ipmi; } > > > > >> console gwn6 { include ipmi; } > > > > >> console gwn7 { include ipmi; } > > > > >> console gwn8 { include ipmi; } > > > > >> > > > > >> console gwc2 { include ipmi; } > > > > >> ---- 8< ---- > > > > >> > > > > >> This has console logging (including possible panics) as a surplus > > > > >> > > > > >> -- > > > > >> Sincerely, > > > > >> D.Marck [DM5020, MCK-RIPE, > > > DM3-RIPN] > > > > >> [ FreeBSD committer: > marck@FreeBSD.org > > > ] > > > > >> > > > > ------------------------------------------------------------------------ > > > > >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- > marck@rinet.ru > > > *** > > > > >> > > > > ------------------------------------------------------------------------ > > > > > > > > > > Hello again, > > > > > > > > > > Searching on hw.uart.console, I found: > > > > > > > > > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > > > > > , a very enlightening thread. > > > > > > > > > > Basically: "ohh, you want to use something other than COM1 and > tried > to > > > > > get away with just changing hint.uart stuff, which has worked for a > > > while, > > > > > ha, no way..." No heads up, nothing. > > > > > > > > > > Sorry to say jhb@ but is not a rare case. It is if not the > default, a > > > > > very common setup on every HP server with iLO, and it holds for > most > > > all > > > > > OOB style serial emulation I have ever had the (dis)pleasure of > working > > > > > with. > > > > > > This was done _specifically_ so you could use non-COM1 for both loader > and > > > kernel with one thing to change. That is, you don't use > hint.uart.X.flags > > > after this. I have used this with many SuperMicro servers that use > COM2 > > > and > > > COM3 because I wanted the entire path (boot loader and kernel) to work, > not > > > the kernel only. Having only the kernel means I can't break into the > > > loader > > > prompt to boot a different kernel, single user, etc. > > > > > > To clarify, are you using _different_ serial ports for the loader vs > the > > > kernel? That is the use case I considered to be rare. Every single > server > > > I have ever worked with (though not iLO, mostly Dell and SuperMicro) > uses > > > the > > > same COM port for serial redirection rather for SOL or via actual > cables. > > > I've yet to use a system that, for example, used COM1 for the loader > and > > > COM2 > > > for the kernel. You are saying that every HP server uses COM1 for the > > > loader > > > and COM2 for the kernel? > > > > > > -- > > > John Baldwin > > > > > > > Hello, > > > > For Supermicro: > > The box was in a rack when I started this, so I don't really know how the > > bios is setup, but as far as I can gather, getting > > "BTX loader yadda yadda" seems to always happen, on any COM-port. > > The actual output from loading modules and so on only happens with > specific > > settings. Here ( as in an answer to Dmitry I accidentally sent in > private ) > > things seems to be on different COMs: Setting: comconsole_port=0x2F8 > (com2) > > show loader and goes dark on handoff to kernel > > comconsole_port=0x3E8 (com3) show no loader and stays dark > > > > Neither of them gives me console even after successful boot. The only way > > to get serial is setting hw.uart.console="br:9600" explicitly. > > On the SuperMicro systems I have played with (X8DTU and the X9DRW > equivalent), > comconsole_port=0x2f8 worked for both BIOS, loader, and kernel, but for > BIOS > to work I did have to enable Console Redirection in the BIOS. For 2U > machines > (X8DAH at least, I think also for X9 equivalent), SOL was on COM3 instead > of > COM2, but using comconsole_port alone worked for BIOS, loader, and kernel. > > I also set the speed to 115200 (conspeed) which IIRC might have been the > default setting in the BIOS when Console Redirection was enabled via SOL. > You can check that remotely for SOL via ipmitool by seeing what baud rate > it is set to. I think if IPMI expects 115200 and you use 9600, that might > explain black output. > > -- > John Baldwin > Hello, I spent the day with new ( as in directly out of the box ) supermicro x9sc(a/i) machine, which as you say has SOL on com3. I don't have logs available now, but short summary was that only way to get it work was to set the hints.uart and then hw.uart.console="br:9600" ( or another speed ) or some bogus value. I'll get back to you tomorrow with the specifics ( the files contains kenv|grep uart , dmesg | grep uart , tail -4 /boot/loader.conf and results with loader (shown|not shown), kernel output (shown|not shown) and login prompt (shown|not shown). Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 18:26:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB9553D4; Thu, 20 Nov 2014 18:26:10 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39C7832E; Thu, 20 Nov 2014 18:26:10 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id h11so6304596wiw.15 for ; Thu, 20 Nov 2014 10:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wCxDUrA2UG1Gz/Xf3+YNp8drUcPvKUoWR3aNQlAT4dI=; b=dLSqhxQIQvalJhiG6YoPQ5KdXyWhUPhqpTibzKx4eCMSizyNd6nyo3D1/i1YnMpGoL xh+KFamFCNMaSJwK8sXwJKG3tWHMmbtvQ7YChNHt5xM+WQxB4a5nCPwFNbexmyE/dNxw Qf/01HPbDR0Wx5csrbbU1+7ItOu9d3E1fBTtDnVQ8itrhB9NhtTcUPUnNvP1sgjNQxGp dpQ9aB69jGmOmGTT5n0UHj/U494BNQIfjnqioAKi54z69BTYeXX7d7Xnb30yztfOgCFp MhlL73As6ho5/RsaVzJ0OKaR/XXOw+6vzT4qK/1QzYtHO6FZlwLGB8OXR9IIAtktKa7t +tbw== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr69924715wjn.68.1416507968412; Thu, 20 Nov 2014 10:26:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 20 Nov 2014 10:26:08 -0800 (PST) In-Reply-To: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> Date: Thu, 20 Nov 2014 10:26:08 -0800 X-Google-Sender-Auth: RNO5kzpdqgp6onjOgQ11Wzg8FtM Message-ID: Subject: Re: send-pr must live From: Adrian Chadd To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: Muhammad Moinur Rahman <5u623l20@gmail.com>, "freebsd-hackers@freebsd.org" , Waitman Gobble , FreeBSD CURRENT , FreeBSD STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:26:10 -0000 Hi! If you'd like to make it work then please do - just make sure you check with the bugteam about it. I'm worried that you're signing them up for more work (dealing with email spam again) which I /think/ they don't have to deal with now. -adrian On 20 November 2014 10:09, Chris H wrote: > On Thu, 20 Nov 2014 09:40:16 -0800 "Waitman Gobble" wrote > >> On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: >> > Nice idea. However I am working on reviving porttools to migrate within >> > bugzilla system. Maybe we can share some ideas. >> > >> > BR, >> > Muhammad >> > >> > >> > On Thu, Nov 20, 2014 at 11:07 PM, Chris H wrote: >> > >> > >> >> Greetings, >> >> While I recognize that send-pr has pretty much >> >> become useless, with the advent of bugzilla, being made the new >> >> "official" FreeBSD bug reporting system. I really >> >> miss send-pr, and was hoping I could revive it, eg; integrate it with >> >> bugzilla. I had even contemplated adding a feature that would allow it >> >> to also work with local port/system building structures people often use >> >> to build, and maintain FreeBSD. Any objections to my reviving send-pr? >> >> >> >> >> >> Thank you for all your time, and consideration. >> >> >> >> >> >> --Chris >> >> >> >> >> >> >> >> _______________________________________________ >> >> freebsd-current@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to >> >> "freebsd-current-unsubscribe@freebsd.org" >> >> >> >> >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > >> > >> >> I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST >> API but current versions use plugin. Also I believe Bugzilla supports an >> email interface so it could be possible to keep send-pr as a shell script. > Indeed. It is perfectly inclined to use email. Which makes > [initial] integration perfectly *trivial*. :) > As to it having been shell based. While there's nothing wrong with > that at all, in fact it's advantageous in many respects. I was toying > with the idea of perhaps converting (augmenting) it to being Perl > based, by way of a statically linked mini-perl interpreter. I thought > it would better *empower* it, also providing for a more "user friendly" > dialog. But, like I said; just *toying* with the idea. :) > > --Chris > >> >> >> >> -- >> Waitman Gobble >> Los Altos California USA >> +1.510-830-7975 > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 18:59:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D7A7216; Thu, 20 Nov 2014 18:59:43 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 68483A70; Thu, 20 Nov 2014 18:59:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NFC00M1XNIN4N00@hades.sorbs.net>; Thu, 20 Nov 2014 10:04:01 -0800 (PST) Message-id: <546E2C06.7040606@sorbs.net> Date: Thu, 20 Nov 2014 18:59:34 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Dominik Zajac Subject: Re: UEFI Boot fails if legacy mode is disabled completely in settings on ASUS Z87 board References: <546E2752.3060609@banym.de> In-reply-to: <546E2752.3060609@banym.de> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 18:59:43 -0000 Dominik Zajac wrote: > Hi, > > on an ASUS Z87 Pro board, the UEFI boot media only work if the CSM mode > in the Settings of the UEFI are set to "both". This means it is using > UEFI boot and CSM mode for legacy booting. > > If I disable the legacy CSM and configure "UEFI only", the UEFI loader > still loads but when it comes to load the kernel it just stops and the > system is frozen at that point. Same with 10.1 and 11-current USB > install media. > > The system now has FreeBSD 10.1 on one disc installed with UEFI mode and > boots with it as long as the CSM compatibility mode is enabled. > > Has someone a similar problem or behaviour? > Same Mobo, same problem here. > This leads me to the next question. How can I debug or get more > information what fails at this stage of the boot process? I would like > to provide more detailed information and help to debug to hunt this bug > down. > Sorry - I can't help here, I don't have time to debug as too busy fixing broken systems from Sept 1 changes. -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 19:22:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF54CAC4; Thu, 20 Nov 2014 19:22:10 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87DF2ED9; Thu, 20 Nov 2014 19:22:10 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKJN71j009325; Thu, 20 Nov 2014 11:23:07 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Adrian Chadd In-Reply-To: References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net>, From: "Chris H" Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 11:23:07 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: Muhammad Moinur Rahman <5u623l20@gmail.com>, "freebsd-hackers@freebsd.org" , Waitman Gobble , FreeBSD CURRENT , FreeBSD STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 19:22:11 -0000 On Thu, 20 Nov 2014 10:26:08 -0800 Adrian Chadd wrote > On 20 November 2014 10:09, Chris H wrote: > > On Thu, 20 Nov 2014 09:40:16 -0800 "Waitman Gobble" > > wrote > > >> On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: > >> > Nice idea. However I am working on reviving porttools to migrate within > >> > bugzilla system. Maybe we can share some ideas. > >> > > >> > BR, > >> > Muhammad > >> > > >> > > >> > On Thu, Nov 20, 2014 at 11:07 PM, Chris H > >> > wrote: >> > > >> > > >> >> Greetings, > >> >> While I recognize that send-pr has pretty much > >> >> become useless, with the advent of bugzilla, being made the new > >> >> "official" FreeBSD bug reporting system. I really > >> >> miss send-pr, and was hoping I could revive it, eg; integrate it with > >> >> bugzilla. I had even contemplated adding a feature that would allow it > >> >> to also work with local port/system building structures people often > >> >> use to build, and maintain FreeBSD. Any objections to my reviving > >> >> send-pr? >> >> > >> >> > >> >> Thank you for all your time, and consideration. > >> >> > >> >> > >> >> --Chris > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> freebsd-current@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> To unsubscribe, send any mail to > >> >> "freebsd-current-unsubscribe@freebsd.org" > >> >> > >> >> > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to > >> > "freebsd-current-unsubscribe@freebsd.org" >> > > >> > > >> > >> I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST > >> API but current versions use plugin. Also I believe Bugzilla supports an > >> email interface so it could be possible to keep send-pr as a shell script. > > Indeed. It is perfectly inclined to use email. Which makes > > [initial] integration perfectly *trivial*. :) > > As to it having been shell based. While there's nothing wrong with > > that at all, in fact it's advantageous in many respects. I was toying > > with the idea of perhaps converting (augmenting) it to being Perl > > based, by way of a statically linked mini-perl interpreter. I thought > > it would better *empower* it, also providing for a more "user friendly" > > dialog. But, like I said; just *toying* with the idea. :) > > > > --Chris > > > >> > >> > >> > >> -- > >> Waitman Gobble > >> Los Altos California USA > >> +1.510-830-7975 > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Hi! > > If you'd like to make it work then please do - just make sure you > check with the bugteam about it. I'm worried that you're signing them > up for more work (dealing with email spam again) which I /think/ they > don't have to deal with now. > > > -adrian > > Thanks for the reply adrian. Count on it. I hate SPAM more than the bugteam! And as a result, I have some _very_ good strategies already employed. So "keeping things clean" should prove a trivial matter. I've already started the process. I'm loading up a copy of devel/bugzilla44 now. Thanks again, for your reply, Adrian -- even if it was an evil top post. ;) --Chris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 20:14:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A140C7A; Thu, 20 Nov 2014 20:14:41 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11C036B3; Thu, 20 Nov 2014 20:14:41 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id eu11so3191786pac.8 for ; Thu, 20 Nov 2014 12:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ImO27GboyaxhKuKi73WN55bL7CVZzoWjtXXMm6CTE40=; b=gBswdy/tQ6lCFxHfN+OJQNAmh5OqLor7Bfa26uJIhYueV9fhOX/it6YQTtk0qOTegL M5eq8yOX1mnOzRweq94RTLggLWsGWsOVsp3KXTjydXw9tMwuoDIO5TYqvoeMeMTrdtcK cAg+UpuzWKpVMb9C5AGhz8GD5AZrH9YbTj/FQAIRdtg10mqguehXoewr5izXTPph4PBb i28zNvLWFGVaeLi2ORabKuuo6ZrrHbhWIoyQtj80WFgzYpdVJ9GuvrP0rFmjVWmIreNv 7nbpMe8AhJDKDweWayvZ/Ust71PEyA9aqfdCyCc1uOXRmarpMBPtDdn+gf4cmARhe+2N DM7Q== X-Received: by 10.68.194.199 with SMTP id hy7mr205644pbc.17.1416514480586; Thu, 20 Nov 2014 12:14:40 -0800 (PST) Received: from [10.30.20.156] (mobile-166-171-120-059.mycingular.net. [166.171.120.59]) by mx.google.com with ESMTPSA id fl2sm2842043pab.0.2014.11.20.12.14.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 12:14:39 -0800 (PST) References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> Mime-Version: 1.0 (1.0) In-Reply-To: <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 12:14:35 -0800 To: Chris H Cc: Adrian Chadd , FreeBSD STABLE , FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , Muhammad Moinur Rahman <5u623l20@gmail.com>, Waitman Gobble X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 20:14:41 -0000 Please take a look at python-bugzilla (you'll need to install setuptools fro= m ports, then run "easy_install python-bugzilla"). If that interface is suff= icient and easy enough to use, I'll document some quick recipes for how to u= se it on the wiki and import it as a port. Cheers!= From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 20:53:24 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 503EB974 for ; Thu, 20 Nov 2014 20:53:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 263BAB15 for ; Thu, 20 Nov 2014 20:53:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1378CB97E; Thu, 20 Nov 2014 15:53:23 -0500 (EST) From: John Baldwin To: Andreas Nilsson Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles Date: Thu, 20 Nov 2014 13:51:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201411201145.01162.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201411201351.29190.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 20 Nov 2014 15:53:23 -0500 (EST) Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 20:53:24 -0000 On Thursday, November 20, 2014 1:09:06 pm Andreas Nilsson wrote: > On Thu, Nov 20, 2014 at 5:45 PM, John Baldwin wrote: > > > On Wednesday, November 19, 2014 5:15:05 pm Andreas Nilsson wrote: > > > On Wed, Nov 19, 2014 at 8:05 PM, John Baldwin wrote: > > > > > > > On Wednesday, November 19, 2014 05:02:49 PM Andreas Nilsson wrote: > > > > > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson > > > > > > wrote: > > > > > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky > > > > > > wrote: > > > > > >> Daniel, > > > > > >> > > > > > >> nice to see you here too ;) > > > > > >> > > > > > >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: > > > > > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson > > > > wrote: > > > > > >> > > unclear is the word for it :) And thanks for looking into > > this. > > > > > >> > > > > > >> ipmi/ilo is > > > > > >> > > > > > >> > > important on a server os. > > > > > >> > > > > > >> > > I found a reference to it in a ML post: > > > > > >> > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.ht > > > > > >> ml > > > > > >> > > > > > >> > I started that thread :) > > > > > >> > I did get it working on the hardware I was using (Supermicro > > X9SCL- > > F > > > > > >> > > > > > >> and X8SIL-F) > > > > > >> > > > > > >> > I used the following BIOS settings > > > > > >> > > > > > > >> > ? Remote Access - Enabled > > > > > >> > ? Serial Port Number - COM3 > > > > > >> > ? Serial Port Mode - 115200, 8, n, 1 > > > > > >> > ? Flow Control - Hardware > > > > > >> > ? Redirection After BIOS POST - Always > > > > > >> > ? Terminal Type - VT100 > > > > > >> > ? VT-UTF8 Combo Key Support - Disabled > > > > > >> > ? Sredir Memory Display Delay - No Delay > > > > > >> > > > > > > >> > And the following in loader.conf > > > > > >> > # Give preference to VGA console > > > > > >> > console="vidconsole,comconsole" > > > > > >> > # Uncomment below and comment above to give serial console > > > > preference > > > > > >> > #console="comconsole,vidconsole" > > > > > >> > comconsole_speed="115200" > > > > > >> > boot_multicons="YES" > > > > > >> > hint.uart.0.flags="0x0" > > > > > >> > hint.uart.2.at="isa" > > > > > >> > hint.uart.2.port="0x3E8" > > > > > >> > hint.uart.2.flags="0x30" > > > > > >> > > > > > > >> > And this in /etc/ttys > > > > > >> > # IPMI console > > > > > >> > # Note: The Java console viewer doesn't seem to be very smart > > as it > > > > > >> > > > > > >> doesn't > > > > > >> > > > > > >> > # properly support VT100 > > > > > >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on > > secure > > > > > >> > > > > > > >> > I could then access it using ipmitool like so > > > > > >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > > > > >> > [login] > > > > > >> > export TERM=xterm > > > > > >> > > > > > > >> > Note that I wanted vidconsole by default because mostly the > > systems > > > > > >> > > > > > >> were used by people local to them, however we could break into the > > > > loader > > > > > >> and type 'set console=comconsole,vidconsole? and then get > > everything > > > > over > > > > > >> the serial console for remote trouble shooting. > > > > > >> > > > > > >> > You may also wish to check the IPMI configuration via the web > > > > interface > > > > > >> > > > > > >> - by default it will failover to port 0 and it has terrible > > default > > > > > >> passwords. I changed the passwords and forced it to use the > > dedicated > > > > > >> IPMI > > > > > >> port even if nothing was connected to it. > > > > > >> > > > > > >> Well, I'm almost done with most of our SM server, even > > concentrated > > > > > >> console on > > > > > >> our console server with such a simple config: > > > > > >> > > > > > >> ---- 8< ---- > > > > > >> # ipmi/sol console template > > > > > >> default ipmi { > > > > > >> > > > > > >> master localhost; > > > > > >> type exec; > > > > > >> exec /usr/local/bin/ipmitool -f > > /usr/local/etc/ipmi-pass - > > U > > > > > >> > > > > > >> root -I lanplus -H %.int sol activate; > > > > > >> > > > > > >> execsubst %=cs; > > > > > >> #idletimeout 6h; > > > > > >> > > > > > >> break 0 { string "~B"; } > > > > > >> > > > > > >> } > > > > > >> > > > > > >> console gwn1 { include ipmi; } > > > > > >> console gwn2 { include ipmi; } > > > > > >> console gwn3 { include ipmi; } > > > > > >> console gwn4 { include ipmi; } > > > > > >> console gwn5 { include ipmi; } > > > > > >> console gwn6 { include ipmi; } > > > > > >> console gwn7 { include ipmi; } > > > > > >> console gwn8 { include ipmi; } > > > > > >> > > > > > >> console gwc2 { include ipmi; } > > > > > >> ---- 8< ---- > > > > > >> > > > > > >> This has console logging (including possible panics) as a surplus > > > > > >> > > > > > >> -- > > > > > >> Sincerely, > > > > > >> D.Marck [DM5020, MCK-RIPE, > > > > DM3-RIPN] > > > > > >> [ FreeBSD committer: > > marck@FreeBSD.org > > > > ] > > > > > >> > > > > > > ------------------------------------------------------------------------ > > > > > >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- > > marck@rinet.ru > > > > *** > > > > > >> > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > Hello again, > > > > > > > > > > > > Searching on hw.uart.console, I found: > > > > > > > > > > > > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > > > > > > , a very enlightening thread. > > > > > > > > > > > > Basically: "ohh, you want to use something other than COM1 and > > tried > > to > > > > > > get away with just changing hint.uart stuff, which has worked for a > > > > while, > > > > > > ha, no way..." No heads up, nothing. > > > > > > > > > > > > Sorry to say jhb@ but is not a rare case. It is if not the > > default, a > > > > > > very common setup on every HP server with iLO, and it holds for > > most > > > > all > > > > > > OOB style serial emulation I have ever had the (dis)pleasure of > > working > > > > > > with. > > > > > > > > This was done _specifically_ so you could use non-COM1 for both loader > > and > > > > kernel with one thing to change. That is, you don't use > > hint.uart.X.flags > > > > after this. I have used this with many SuperMicro servers that use > > COM2 > > > > and > > > > COM3 because I wanted the entire path (boot loader and kernel) to work, > > not > > > > the kernel only. Having only the kernel means I can't break into the > > > > loader > > > > prompt to boot a different kernel, single user, etc. > > > > > > > > To clarify, are you using _different_ serial ports for the loader vs > > the > > > > kernel? That is the use case I considered to be rare. Every single > > server > > > > I have ever worked with (though not iLO, mostly Dell and SuperMicro) > > uses > > > > the > > > > same COM port for serial redirection rather for SOL or via actual > > cables. > > > > I've yet to use a system that, for example, used COM1 for the loader > > and > > > > COM2 > > > > for the kernel. You are saying that every HP server uses COM1 for the > > > > loader > > > > and COM2 for the kernel? > > > > > > > > -- > > > > John Baldwin > > > > > > > > > > Hello, > > > > > > For Supermicro: > > > The box was in a rack when I started this, so I don't really know how the > > > bios is setup, but as far as I can gather, getting > > > "BTX loader yadda yadda" seems to always happen, on any COM-port. > > > The actual output from loading modules and so on only happens with > > specific > > > settings. Here ( as in an answer to Dmitry I accidentally sent in > > private ) > > > things seems to be on different COMs: Setting: comconsole_port=0x2F8 > > (com2) > > > show loader and goes dark on handoff to kernel > > > comconsole_port=0x3E8 (com3) show no loader and stays dark > > > > > > Neither of them gives me console even after successful boot. The only way > > > to get serial is setting hw.uart.console="br:9600" explicitly. > > > > On the SuperMicro systems I have played with (X8DTU and the X9DRW > > equivalent), > > comconsole_port=0x2f8 worked for both BIOS, loader, and kernel, but for > > BIOS > > to work I did have to enable Console Redirection in the BIOS. For 2U > > machines > > (X8DAH at least, I think also for X9 equivalent), SOL was on COM3 instead > > of > > COM2, but using comconsole_port alone worked for BIOS, loader, and kernel. > > > > I also set the speed to 115200 (conspeed) which IIRC might have been the > > default setting in the BIOS when Console Redirection was enabled via SOL. > > You can check that remotely for SOL via ipmitool by seeing what baud rate > > it is set to. I think if IPMI expects 115200 and you use 9600, that might > > explain black output. > > > > -- > > John Baldwin > > > > Hello, > > I spent the day with new ( as in directly out of the box ) supermicro > x9sc(a/i) machine, which as you say has SOL on com3. I don't have logs > available now, but short summary was that only way to get it work was to > set the hints.uart and then hw.uart.console="br:9600" ( or another speed ) > or some bogus value. > > I'll get back to you tomorrow with the specifics ( the files contains > kenv|grep uart , dmesg | grep uart , tail -4 /boot/loader.conf and results > with loader (shown|not shown), kernel output (shown|not shown) and login > prompt (shown|not shown). ipmitool sol info would also be good to have, e.g.: Set in progress : set-complete Enabled : true Force Encryption : true Force Authentication : true Privilege Level : USER Character Accumulate Level (ms) : 60 Character Send Threshold : 96 Retry Count : 7 Retry Interval (ms) : 1000 Volatile Bit Rate (kbps) : 115.2 Non-Volatile Bit Rate (kbps) : 115.2 Payload Channel : 1 (0x01) Payload Port : 623 is from an X8DTU system. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 21:01:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DBBCE1; Thu, 20 Nov 2014 21:01:56 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3D4EC41; Thu, 20 Nov 2014 21:01:55 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id u10so2985523lbd.3 for ; Thu, 20 Nov 2014 13:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ceZgShFMiNzjr+oF+6+kE35vstk7/QM8dnslGSgIdpI=; b=YyS6PCUPTKsuGIFBGtls4cc2BafUUtEmRZm+klU9CPj45pCZSlXj45B09p923et5SU fqpG9ChBQROlPUe8oU/XQKDhcBtFR7H7i+7U/no6OPzTWX5pshAAZxa3rD3aWVLTGbCI CnrLkalPT/C/HkBjZqcKQo7ISV/ao4jl1fqlP5THj/dT92Q5jQMsY6IrBd6UUkEpOShO Bclp+Uek94tWiH46vcw/CRQNpIQTygU5ST3NW6qh6yEcIeiV9euSeiXaJMfuZGiLAZtJ 3ZX7TCt06hMx0/zqILYa3FKLFEaexZH6euFsb3hFdaUlA1DF1Vcfkxu23CV8q20Zfv2u Rb5g== MIME-Version: 1.0 X-Received: by 10.112.139.196 with SMTP id ra4mr275582lbb.95.1416517312441; Thu, 20 Nov 2014 13:01:52 -0800 (PST) Received: by 10.25.170.66 with HTTP; Thu, 20 Nov 2014 13:01:52 -0800 (PST) In-Reply-To: <201411201351.29190.jhb@freebsd.org> References: <201411201145.01162.jhb@freebsd.org> <201411201351.29190.jhb@freebsd.org> Date: Thu, 20 Nov 2014 22:01:52 +0100 Message-ID: Subject: Re: SuperMicro IPMI/SOL and ipmitool troubles From: Andreas Nilsson To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Daniel O'Connor , FreeBSD Stable Mailing List , Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 21:01:56 -0000 On Thu, Nov 20, 2014 at 7:51 PM, John Baldwin wrote: > On Thursday, November 20, 2014 1:09:06 pm Andreas Nilsson wrote: > > On Thu, Nov 20, 2014 at 5:45 PM, John Baldwin wrote: > > > > > On Wednesday, November 19, 2014 5:15:05 pm Andreas Nilsson wrote: > > > > On Wed, Nov 19, 2014 at 8:05 PM, John Baldwin > wrote: > > > > > > > > > On Wednesday, November 19, 2014 05:02:49 PM Andreas Nilsson wrote: > > > > > > On Wed, Nov 19, 2014 at 3:28 PM, Andreas Nilsson < > andrnils@gmail.com > > > > > > > > > wrote: > > > > > > > On Fri, Nov 14, 2014 at 7:30 PM, Dmitry Morozovsky < > marck@rinet.ru > > > > > > > > > wrote: > > > > > > >> Daniel, > > > > > > >> > > > > > > >> nice to see you here too ;) > > > > > > >> > > > > > > >> On Fri, 14 Nov 2014, Daniel O'Connor wrote: > > > > > > >> > On 12 Nov 2014, at 19:43, Andreas Nilsson < > andrnils@gmail.com> > > > > > wrote: > > > > > > >> > > unclear is the word for it :) And thanks for looking into > > > this. > > > > > > >> > > > > > > >> ipmi/ilo is > > > > > > >> > > > > > > >> > > important on a server os. > > > > > > >> > > > > > > >> > > I found a reference to it in a ML post: > > > > > > >> > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072464.ht > > > > > > >> ml > > > > > > >> > > > > > > >> > I started that thread :) > > > > > > >> > I did get it working on the hardware I was using (Supermicro > > > X9SCL- > > > F > > > > > > >> > > > > > > >> and X8SIL-F) > > > > > > >> > > > > > > >> > I used the following BIOS settings > > > > > > >> > > > > > > > >> > ? Remote Access - Enabled > > > > > > >> > ? Serial Port Number - COM3 > > > > > > >> > ? Serial Port Mode - 115200, 8, n, 1 > > > > > > >> > ? Flow Control - Hardware > > > > > > >> > ? Redirection After BIOS POST - Always > > > > > > >> > ? Terminal Type - VT100 > > > > > > >> > ? VT-UTF8 Combo Key Support - Disabled > > > > > > >> > ? Sredir Memory Display Delay - No Delay > > > > > > >> > > > > > > > >> > And the following in loader.conf > > > > > > >> > # Give preference to VGA console > > > > > > >> > console="vidconsole,comconsole" > > > > > > >> > # Uncomment below and comment above to give serial console > > > > > preference > > > > > > >> > #console="comconsole,vidconsole" > > > > > > >> > comconsole_speed="115200" > > > > > > >> > boot_multicons="YES" > > > > > > >> > hint.uart.0.flags="0x0" > > > > > > >> > hint.uart.2.at="isa" > > > > > > >> > hint.uart.2.port="0x3E8" > > > > > > >> > hint.uart.2.flags="0x30" > > > > > > >> > > > > > > > >> > And this in /etc/ttys > > > > > > >> > # IPMI console > > > > > > >> > # Note: The Java console viewer doesn't seem to be very > smart > > > as it > > > > > > >> > > > > > > >> doesn't > > > > > > >> > > > > > > >> > # properly support VT100 > > > > > > >> > cuau2 "/usr/libexec/getty 3wire.115200" vt100 on > > > secure > > > > > > >> > > > > > > > >> > I could then access it using ipmitool like so > > > > > > >> > ipmitool -H remoteip -U ADMIN -I lanplus sol activate > > > > > > >> > [login] > > > > > > >> > export TERM=xterm > > > > > > >> > > > > > > > >> > Note that I wanted vidconsole by default because mostly the > > > systems > > > > > > >> > > > > > > >> were used by people local to them, however we could break > into the > > > > > loader > > > > > > >> and type 'set console=comconsole,vidconsole? and then get > > > everything > > > > > over > > > > > > >> the serial console for remote trouble shooting. > > > > > > >> > > > > > > >> > You may also wish to check the IPMI configuration via the > web > > > > > interface > > > > > > >> > > > > > > >> - by default it will failover to port 0 and it has terrible > > > default > > > > > > >> passwords. I changed the passwords and forced it to use the > > > dedicated > > > > > > >> IPMI > > > > > > >> port even if nothing was connected to it. > > > > > > >> > > > > > > >> Well, I'm almost done with most of our SM server, even > > > concentrated > > > > > > >> console on > > > > > > >> our console server with such a simple config: > > > > > > >> > > > > > > >> ---- 8< ---- > > > > > > >> # ipmi/sol console template > > > > > > >> default ipmi { > > > > > > >> > > > > > > >> master localhost; > > > > > > >> type exec; > > > > > > >> exec /usr/local/bin/ipmitool -f > > > /usr/local/etc/ipmi-pass - > > > U > > > > > > >> > > > > > > >> root -I lanplus -H %.int sol activate; > > > > > > >> > > > > > > >> execsubst %=cs; > > > > > > >> #idletimeout 6h; > > > > > > >> > > > > > > >> break 0 { string "~B"; } > > > > > > >> > > > > > > >> } > > > > > > >> > > > > > > >> console gwn1 { include ipmi; } > > > > > > >> console gwn2 { include ipmi; } > > > > > > >> console gwn3 { include ipmi; } > > > > > > >> console gwn4 { include ipmi; } > > > > > > >> console gwn5 { include ipmi; } > > > > > > >> console gwn6 { include ipmi; } > > > > > > >> console gwn7 { include ipmi; } > > > > > > >> console gwn8 { include ipmi; } > > > > > > >> > > > > > > >> console gwc2 { include ipmi; } > > > > > > >> ---- 8< ---- > > > > > > >> > > > > > > >> This has console logging (including possible panics) as a > surplus > > > > > > >> > > > > > > >> -- > > > > > > >> Sincerely, > > > > > > >> D.Marck [DM5020, MCK-RIPE, > > > > > DM3-RIPN] > > > > > > >> [ FreeBSD committer: > > > marck@FreeBSD.org > > > > > ] > > > > > > >> > > > > > > > > > ------------------------------------------------------------------------ > > > > > > >> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- > > > marck@rinet.ru > > > > > *** > > > > > > >> > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > Hello again, > > > > > > > > > > > > > > Searching on hw.uart.console, I found: > > > > > > > > > > > > > > > > http://lists.freebsd.org/pipermail/svn-src-head/2013-February/044641.html > > > > > > > , a very enlightening thread. > > > > > > > > > > > > > > Basically: "ohh, you want to use something other than COM1 and > > > tried > > > to > > > > > > > get away with just changing hint.uart stuff, which has worked > for a > > > > > while, > > > > > > > ha, no way..." No heads up, nothing. > > > > > > > > > > > > > > Sorry to say jhb@ but is not a rare case. It is if not the > > > default, a > > > > > > > very common setup on every HP server with iLO, and it holds for > > > most > > > > > all > > > > > > > OOB style serial emulation I have ever had the (dis)pleasure of > > > working > > > > > > > with. > > > > > > > > > > This was done _specifically_ so you could use non-COM1 for both > loader > > > and > > > > > kernel with one thing to change. That is, you don't use > > > hint.uart.X.flags > > > > > after this. I have used this with many SuperMicro servers that use > > > COM2 > > > > > and > > > > > COM3 because I wanted the entire path (boot loader and kernel) to > work, > > > not > > > > > the kernel only. Having only the kernel means I can't break into > the > > > > > loader > > > > > prompt to boot a different kernel, single user, etc. > > > > > > > > > > To clarify, are you using _different_ serial ports for the loader > vs > > > the > > > > > kernel? That is the use case I considered to be rare. Every > single > > > server > > > > > I have ever worked with (though not iLO, mostly Dell and > SuperMicro) > > > uses > > > > > the > > > > > same COM port for serial redirection rather for SOL or via actual > > > cables. > > > > > I've yet to use a system that, for example, used COM1 for the > loader > > > and > > > > > COM2 > > > > > for the kernel. You are saying that every HP server uses COM1 for > the > > > > > loader > > > > > and COM2 for the kernel? > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > > > > > > Hello, > > > > > > > > For Supermicro: > > > > The box was in a rack when I started this, so I don't really know > how the > > > > bios is setup, but as far as I can gather, getting > > > > "BTX loader yadda yadda" seems to always happen, on any COM-port. > > > > The actual output from loading modules and so on only happens with > > > specific > > > > settings. Here ( as in an answer to Dmitry I accidentally sent in > > > private ) > > > > things seems to be on different COMs: Setting: comconsole_port=0x2F8 > > > (com2) > > > > show loader and goes dark on handoff to kernel > > > > comconsole_port=0x3E8 (com3) show no loader and stays dark > > > > > > > > Neither of them gives me console even after successful boot. The > only way > > > > to get serial is setting hw.uart.console="br:9600" explicitly. > > > > > > On the SuperMicro systems I have played with (X8DTU and the X9DRW > > > equivalent), > > > comconsole_port=0x2f8 worked for both BIOS, loader, and kernel, but for > > > BIOS > > > to work I did have to enable Console Redirection in the BIOS. For 2U > > > machines > > > (X8DAH at least, I think also for X9 equivalent), SOL was on COM3 > instead > > > of > > > COM2, but using comconsole_port alone worked for BIOS, loader, and > kernel. > > > > > > I also set the speed to 115200 (conspeed) which IIRC might have been > the > > > default setting in the BIOS when Console Redirection was enabled via > SOL. > > > You can check that remotely for SOL via ipmitool by seeing what baud > rate > > > it is set to. I think if IPMI expects 115200 and you use 9600, that > might > > > explain black output. > > > > > > -- > > > John Baldwin > > > > > > > Hello, > > > > I spent the day with new ( as in directly out of the box ) supermicro > > x9sc(a/i) machine, which as you say has SOL on com3. I don't have logs > > available now, but short summary was that only way to get it work was to > > set the hints.uart and then hw.uart.console="br:9600" ( or another speed > ) > > or some bogus value. > > > > I'll get back to you tomorrow with the specifics ( the files contains > > kenv|grep uart , dmesg | grep uart , tail -4 /boot/loader.conf and > results > > with loader (shown|not shown), kernel output (shown|not shown) and login > > prompt (shown|not shown). > > ipmitool sol info would also be good to have, e.g.: > > Set in progress : set-complete > Enabled : true > Force Encryption : true > Force Authentication : true > Privilege Level : USER > Character Accumulate Level (ms) : 60 > Character Send Threshold : 96 > Retry Count : 7 > Retry Interval (ms) : 1000 > Volatile Bit Rate (kbps) : 115.2 > Non-Volatile Bit Rate (kbps) : 115.2 > Payload Channel : 1 (0x01) > Payload Port : 623 > > is from an X8DTU system. > > -- > John Baldwin > Sure thing, below is the output from the machine where this started, for me at least. Still a X9SCI/X9SCA machine: Set in progress : set-complete Enabled : true Force Encryption : false Force Authentication : false Privilege Level : USER Character Accumulate Level (ms) : 0 Character Send Threshold : 0 Retry Count : 0 Retry Interval (ms) : 0 Volatile Bit Rate (kbps) : 115.2 Non-Volatile Bit Rate (kbps) : 115.2 Payload Channel : 1 (0x01) Payload Port : 623 Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 21:50:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581E5A08; Thu, 20 Nov 2014 21:50:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 285B118E; Thu, 20 Nov 2014 21:50:23 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sAKLpJeE058720; Thu, 20 Nov 2014 13:51:20 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Garrett Cooper In-Reply-To: References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net>, From: "Chris H" Subject: Re: send-pr must live Date: Thu, 20 Nov 2014 13:51:20 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <83bde838aaa0d084c046e11363f41d59@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: Adrian Chadd , FreeBSD STABLE , FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , Muhammad Moinur Rahman <5u623l20@gmail.com>, Waitman Gobble X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 21:50:23 -0000 On Thu, 20 Nov 2014 12:14:35 -0800 Garrett Cooper wrote > Please take a look at python-bugzilla Hmm... no sign of it. Do you possibly mean; py-bugzillatools? Just groping. > (you'll need to install setuptools from > ports, then run "easy_install python-bugzilla"). If that interface is > sufficient and easy enough to use, I'll document some quick recipes for how > to use it on the wiki and import it as a port. > > Cheers! --Chris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 20 23:10:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 299B14DA; Thu, 20 Nov 2014 23:10:31 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E04A6C6C; Thu, 20 Nov 2014 23:10:30 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id y20so3828228ier.18 for ; Thu, 20 Nov 2014 15:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UTXX32UakTY9K51pmn6MuUjWXVzuYawmydeBw/4c4fU=; b=PtUtubZLP5ei385Pg4Fkh076mM5UupsolmOzOMpvNQefaGl/4xIsL4/ESRmt/kLM5E JLeJxEczjJ0RVVMHeNBkOLNslYBQYDQ/7qljhuafNMMop+D/ptgzRu6aJyTKv+vJOsMT 3BTkvwcbgJWoF9xhD3auiekeCzL8WpnUVpLUjLasXcfemc+iSkBOg6N1ee0sXNgjTWwy 4LEKyViwaBPoLAbtN7puKLQsOLJXIqgUV0rq3RiTLHOt3f/daFWmaM08yXyKNeA9T2Uo MZh89zIvmJMRBN86S+oLTXJrbLor3vcrY7W8EPqHePdVic0y5AXTP5KjyBa/IGBk17pw AIAg== MIME-Version: 1.0 X-Received: by 10.50.39.80 with SMTP id n16mr587055igk.49.1416525030159; Thu, 20 Nov 2014 15:10:30 -0800 (PST) Received: by 10.50.42.162 with HTTP; Thu, 20 Nov 2014 15:10:30 -0800 (PST) In-Reply-To: <83bde838aaa0d084c046e11363f41d59@ultimatedns.net> References: <11d24756184c5b6f3339f6e645957f86@ultimatedns.net> <9898ebc3c470ac0c6e3df470c6028e90@ultimatedns.net> <83bde838aaa0d084c046e11363f41d59@ultimatedns.net> Date: Thu, 20 Nov 2014 15:10:30 -0800 Message-ID: Subject: Re: send-pr must live From: NGie Cooper To: Chris H Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , FreeBSD STABLE , FreeBSD CURRENT , "freebsd-hackers@freebsd.org" , Muhammad Moinur Rahman <5u623l20@gmail.com>, Waitman Gobble X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Nov 2014 23:10:31 -0000 On Thu, Nov 20, 2014 at 1:51 PM, Chris H wrote: > On Thu, 20 Nov 2014 12:14:35 -0800 Garrett Cooper wrote > >> Please take a look at python-bugzilla > Hmm... no sign of it. Do you possibly mean; py-bugzillatools? > Just groping. All the hints were in my original reply... [root@wkstn-lnx-ngie ngie]# easy_install python-bugzilla Searching for python-bugzilla Reading https://pypi.python.org/simple/python-bugzilla/ Best match: python-bugzilla 1.1.0 Downloading https://pypi.python.org/packages/source/p/python-bugzilla/python-bugzilla-1.1.0.tar.gz#md5=c95befd1fecad21f742beaa8180538c0 Processing python-bugzilla-1.1.0.tar.gz Writing /tmp/easy_install-lR6lpK/python-bugzilla-1.1.0/setup.cfg Running python-bugzilla-1.1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-lR6lpK/python-bugzilla-1.1.0/egg-dist-tmp-yjKZ_J zip_safe flag not set; analyzing archive contents... Adding python-bugzilla 1.1.0 to easy-install.pth file Installing bugzilla script to /usr/bin Installed /usr/lib/python2.7/site-packages/python_bugzilla-1.1.0-py2.7.egg Processing dependencies for python-bugzilla Finished processing dependencies for python-bugzilla From owner-freebsd-stable@FreeBSD.ORG Fri Nov 21 08:12:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9C23583 for ; Fri, 21 Nov 2014 08:12:04 +0000 (UTC) Received: from mailrelay8.public.one.com (mailrelay8.public.one.com [91.198.169.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E800A54 for ; Fri, 21 Nov 2014 08:12:03 +0000 (UTC) X-HalOne-Cookie: fc12c10a3094eee8c21d28c2161b9a2d563acb2b DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cederstrand.dk; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=6+SEgozgBROlDHTlOILIqgpwgZ8ByuXjD/blWnHBg7Q=; b=sT869UsLVMDICKgUPwIiNZaRc8JXnszU708jL72sULY2oqH/Iwz5CqDQ6piwe233Cz2YwDvju2mUX IAHkVjMogxcdTuDUmkKJujKsq8zFyY+Wyob9X/FayrRFOAVWJYpJlGAa5QDEl6EYGNnw46OKveOsq1 Itk7zwqoQA5ywI3s= Received: from [192.168.1.58] (unknown [217.157.7.221]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA; Fri, 21 Nov 2014 08:08:04 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: send-pr must live From: Erik Cederstrand In-Reply-To: Date: Fri, 21 Nov 2014 09:10:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37F1EA3C-BAEC-4BC9-8EAD-8C5CC74295BA@cederstrand.dk> References: To: Chris H X-Mailer: Apple Mail (2.1993) Cc: freebsd-hackers@freebsd.org, FreeBSD STABLE , FreeBSD CURRENT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 08:12:04 -0000 > Den 20/11/2014 kl. 18.07 skrev Chris H : >=20 > Greetings, > While I recognize that send-pr has pretty much > become useless, with the advent of bugzilla, being made > the new "official" FreeBSD bug reporting system. I really > miss send-pr, and was hoping I could revive it, eg; > integrate it with bugzilla. I had even contemplated adding > a feature that would allow it to also work with local > port/system building structures people often use to build, > and maintain FreeBSD. The original send-pr simply send an email to = freebsd-gnats-submit@freebsd.org. I wrote a script some years ago to = parse the contents of that email and import it into Bugzilla using the = Bugzilla XML-RPC API: https://github.com/ecederstrand/send-pr The advantage is that no changes are necessary to the original send-pr = because the script would run on a freebsd.org server. I haven't adapted = it to the Bugzilla that is running now, but it should be fairly easy. = Maybe this could be of use? Erik= From owner-freebsd-stable@FreeBSD.ORG Fri Nov 21 10:28:52 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9FD13ED; Fri, 21 Nov 2014 10:28:52 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CD78AB2; Fri, 21 Nov 2014 10:28:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sALASM12063563; Fri, 21 Nov 2014 13:28:22 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 21 Nov 2014 13:28:22 +0300 (MSK) From: Dmitry Morozovsky To: Steven Hartland Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] In-Reply-To: Message-ID: References: <-7425247475772590723@unknownmsgid> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Fri, 21 Nov 2014 13:28:22 +0300 (MSK) Cc: "stable@freebsd.org" , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 10:28:52 -0000 Steven, colleagues, any news on this? I now have a bunch of cores, most from my own experiments, but also from daily find, all with similar sympthoms. On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > On Tue, 18 Nov 2014, Steven Hartland wrote: > > > > > Can u plug a usb drive in to get a dump? > > > > Hm, will it work over USB stack? I can try this. > > > > BTW: it seems some internal ZFS locking trouble exists, as trere are 3 cases: > > > > pool/R/fs1 mounted as /fs1 > > pool/R/fs2 > > pool/R/fs3 > > > > tar cf - /fs1 >/dev/null works ok > > tar cf - /fs2 >/dev/null works ok > > rsync -avHP /fs1/ /fs2/ panics in few minutes > > > > will try to configure dump to USB SATA > > wow, it works ;) > > not on the first trial, but anyway, here we go: > > #0 doadump (textdump=1621911824) at pcpu.h:219 > #1 0xffffffff803471d5 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) at /usr/src/sys/ddb/db_command.c:568 > #2 0xffffffff80346ebd in db_command (cmd_table=0x0) at > /usr/src/sys/ddb/db_command.c:440 > #3 0xffffffff80346c34 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:493 > #4 0xffffffff80349580 in db_trap (type=, code=0) at > /usr/src/sys/ddb/db_main.c:231 > #5 0xffffffff80940cd9 in kdb_trap (type=3, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:656 > #6 0xffffffff80ce8ca3 in trap (frame=0xfffffe0860ac6d40) at > /usr/src/sys/amd64/amd64/trap.c:556 > #7 0xffffffff80ccf492 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:232 > #8 0xffffffff8094043e in kdb_enter (why=0xffffffff80f5b27c "panic", msg= optimized out>) at cpufunc.h:63 > #9 0xffffffff80908f76 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:752 > #10 0xffffffff80908fe3 in panic (fmt=0xffffffff8154f850 "\004") at > /usr/src/sys/kern/kern_shutdown.c:688 > #11 0xffffffff80b64502 in vm_fault_hold (map=, > vaddr=, fault_type=, > fault_flags=, m_hold=) at > /usr/src/sys/vm/vm_fault.c:341 > #12 0xffffffff80b62b87 in vm_fault (map=0xfffff80002000000, vaddr= optimized out>, fault_type=1 '\001', fault_flags=128) > at /usr/src/sys/vm/vm_fault.c:281 > #13 0xffffffff80ce9551 in trap_pfault (frame=0xfffffe0860ac7400, usermode=0) at > /usr/src/sys/amd64/amd64/trap.c:752 > #14 0xffffffff80ce8cba in trap (frame=0xfffffe0860ac7400) at > /usr/src/sys/amd64/amd64/trap.c:440 > #15 0xffffffff80ccf492 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:232 > #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, > h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 > #17 0xffffffff81b688ee in fzap_cursor_retrieve (zap=0xfffff8001676ce80, > zc=0xfffffe0860ac77d8, za=0xfffffe0860ac76c0) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1190 > #18 0xffffffff81b6dc97 in zap_cursor_retrieve (zc=0xfffffe0860ac77d8, > za=0xfffffe0860ac76c0) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 > #19 0xffffffff81ba8f16 in zfs_freebsd_readdir (ap=) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2565 > #20 0xffffffff80e03967 in VOP_READDIR_APV (vop=, a= optimized out>) at vnode_if.c:1821 > #21 0xffffffff809b1d1c in kern_getdirentries (td=0xfffff80025ff1490, fd= optimized out>, > buf=0x801428000
, count= out>, basep=0xfffffe0860ac7990, residp=0x0) > at vnode_if.h:758 > #22 0xffffffff809b1ad8 in sys_getdirentries (td=0xfffff801bd6ec880, > uap=0xfffffe0860ac7a40) at /usr/src/sys/kern/vfs_syscalls.c:4030 > #23 0xffffffff80ce9aca in amd64_syscall (td=0xfffff80025ff1490, traced=0) at > subr_syscall.c:134 > #24 0xffffffff80ccf77b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:391 > #25 0x000000080091043a in ?? () > > #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, > h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 > 466 if (HCD_GTEQ(le->le_hash, le->le_cd, h, cd) && > (kgdb) p *le->le_hash > No symbol "le" in current context. > (kgdb) p le > No symbol "le" in current context. > (kgdb) p h > $1 = 1441072784640835584 > (kgdb) p *h > Cannot access memory at address 0x13ffb81000000000 > (kgdb) p cd > $2 = 1 > > where now? > > > > > > > > > > > > > On 18 Nov 2014, at 16:57, Dmitry Morozovsky wrote: > > > > > > > >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > >> > > > >> my backup server after updrade to frest stable/10 > > > >> > > > >> start panicing on heavy disk load like rsync at > > > > > > > > Yes, it is reproducible easy and now I'm at ddb prompt with > > > > > > > > cpuid = 0 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0860864d60 > > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 > > > > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 > > > > panic() at panic+0x43/frame 0xfffffe0860864eb0 > > > > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 > > > > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 > > > > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 > > > > trap() at trap+0x47a/frame 0xfffffe08608653f0 > > > > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 > > > > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, rbp = > > > > 0xfffffe0860865500 --- > > > > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame > > > > 0xfffffe0860865500 > > > > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame 0xfffffe0860865570 > > > > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame 0xfffffe0860865600 > > > > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame 0xfffffe0860865840 > > > > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 > > > > kern_getdirentries() at kern_getdirentries+0x21c/frame 0xfffffe0860865970 > > > > sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe08608659a0 > > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 > > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 > > > > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x80091043a, rsp = > > > > 0x7fffffffb538, rbp = 0x7fffffffb560 --- > > > > KDB: enter: panic > > > > [ thread pid 1167 tid 100461 ] > > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > db> > > > > > > > > Can I obtain somthing useful from here? I'm afraid it's not easy to attach > > > > additional disk for crash dumps to this server... > > > > > > > > > > > >> > > > >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 r274646: Tue Nov 18 > > > >> 12:15:24 MSK 2014 > > > >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC amd64 > > > >> > > > >> > > > >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 > > > >> cpuid = 0 > > > >> KDB: stack backtrace: > > > >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 > > > >> #1 0xffffffff8092a085 at panic+0x155 > > > >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e > > > >> #3 0xffffffff80b9fad7 at vm_fault+0x77 > > > >> #4 0xffffffff80d2861c at trap_pfault+0x19c > > > >> #5 0xffffffff80d27dea at trap+0x47a > > > >> #6 0xffffffff80d0db92 at calltrap+0x8 > > > >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e > > > >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 > > > >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 > > > >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 > > > >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c > > > >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 > > > >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 > > > >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb > > > >> Uptime: 1m51s > > > >> > > > >> Unfortunately it's ZFS only, so I have no space to white panic dump. > > > >> > > > >> I'm now trying to rebuild kernel with debugger turned on, as luckily I have > > > >> working console@SOL... > > > >> > > > >> Any preliminary hints? > > > >> > > > >> > > > > > > > > -- > > > > Sincerely, > > > > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > > > [ FreeBSD committer: marck@FreeBSD.org ] > > > > ------------------------------------------------------------------------ > > > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > > > 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" > > > > > > > > > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Nov 21 11:46:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B8C429F for ; Fri, 21 Nov 2014 11:46:27 +0000 (UTC) Received: from pluto.backlogs.co.uk (pluto.backlogs.co.uk [95.128.128.31]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "pluto.backlogs.co.uk", Issuer "pluto.backlogs.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2576B340 for ; Fri, 21 Nov 2014 11:46:26 +0000 (UTC) Received: from hawk.gnome.co.uk (hawk.gnome.co.uk [192.168.123.12]) by pluto.backlogs.co.uk (8.14.7/8.14.7) with ESMTP id sALBkM1s067118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Nov 2014 11:46:23 GMT (envelope-from chris@stenton.me.uk) Received: from [192.168.100.3] (mars.backlogs.co.uk [192.168.100.3]) by hawk.gnome.co.uk (8.14.9/8.14.9) with ESMTP id sALBkEN4047577 for ; Fri, 21 Nov 2014 11:46:16 GMT (envelope-from chris@stenton.me.uk) Message-ID: <546F2614.4020800@stenton.me.uk> Date: Fri, 21 Nov 2014 11:46:28 +0000 From: Chris Stenton User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD Stable Mailing List Subject: FreeBSD 10.1 qcow2 image panic on Linux VM hosts Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (pluto.backlogs.co.uk [192.168.100.12]); Fri, 21 Nov 2014 11:46:23 +0000 (GMT) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hawk.gnome.co.uk [192.168.123.12]); Fri, 21 Nov 2014 11:46:16 +0000 (GMT) X-Scanned-By: MIMEDefang 2.75 on 192.168.100.12 X-Scanned-By: MIMEDefang 2.75 on 192.168.123.12 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 11:46:27 -0000 Hi, I am trying to run the vanilla FreeBSD 10.1 qcow2 image on a CENTOS 7 VM Host. I can start it up ok but under a small load it kernel panics. The error is g_vfs_done():vtdb0: hard error gpt/rootfs[WRITE(offset=21890048, length=8704)]cmd=write error = 534 panic:cannot reassign paging buffer cpuid = 1 Dump failed so I am just copying the above from virt-manager console. All I am doing is pkg install emacs24 and it gets as far as "[7/96] Installing perl5-5.16.3_11: 32%" I've tried the Image on a Ubuntu VM host as well and get the same problem. I've tried varying the amount of memory up to 4GB but still the same problem. Other OS's clients run fine. Any ideas? Thanks Chris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 21 11:58:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21E1D6CC for ; Fri, 21 Nov 2014 11:58:42 +0000 (UTC) Received: from pluto.backlogs.co.uk (pluto.backlogs.co.uk [95.128.128.31]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "pluto.backlogs.co.uk", Issuer "pluto.backlogs.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B02C0662 for ; Fri, 21 Nov 2014 11:58:41 +0000 (UTC) Received: from hawk.gnome.co.uk (hawk.gnome.co.uk [192.168.123.12]) by pluto.backlogs.co.uk (8.14.7/8.14.7) with ESMTP id sALBeiSt067055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Nov 2014 11:40:45 GMT (envelope-from chris@stenton.me.uk) Received: from [192.168.100.3] (mars.backlogs.co.uk [192.168.100.3]) by hawk.gnome.co.uk (8.14.9/8.14.9) with ESMTP id sALBeem4047514 for ; Fri, 21 Nov 2014 11:40:42 GMT (envelope-from chris@stenton.me.uk) Message-ID: <546F24C6.60406@stenton.me.uk> Date: Fri, 21 Nov 2014 11:40:54 +0000 From: Chris Stenton User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: FreeBSD Stable Mailing List Subject: FreeBSD 10.1 qcow2 image panic on Linux VM hosts Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (pluto.backlogs.co.uk [192.168.100.12]); Fri, 21 Nov 2014 11:40:45 +0000 (GMT) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hawk.gnome.co.uk [192.168.123.12]); Fri, 21 Nov 2014 11:40:42 +0000 (GMT) X-Scanned-By: MIMEDefang 2.75 on 192.168.100.12 X-Scanned-By: MIMEDefang 2.75 on 192.168.123.12 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 11:58:42 -0000 Hi, I am trying to run the vanilla FreeBSD 10.1 qcow2 image on a CENTOS 7 VM Host. I can start it up ok but under a small load it kernel panics. The error is g_vfs_done():vtdb0: hard error gpt/rootfs[WRITE(offset=21890048, length=8704)]cmd=write error = 534 panic:cannot reassign paging buffer cpuid = 1 Dump failed so I am just copying the above from virt-manager console. All I am doing is pkg install emacs24 and it gets as far as "[7/96] Installing perl5-5.16.3_11: 32%" I've tried the Image on a Ubuntu VM host as well and get the same problem. I've tried varying the amount of memory up to 4GB but still the same problem. Other OS's clients run fine. Any ideas? Thanks Chris From owner-freebsd-stable@FreeBSD.ORG Fri Nov 21 13:44:40 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 540651DD for ; Fri, 21 Nov 2014 13:44:40 +0000 (UTC) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B18B1195 for ; Fri, 21 Nov 2014 13:44:39 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hz20so4135110lab.20 for ; Fri, 21 Nov 2014 05:44:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gK57PwAJ4NbOdBVTLxUMLY318akRWyRNExOD691W+ow=; b=baQyoGXJ7HAH9BwGlY3YPBpIOY6Jm5p3eDOXMZ8ReMeJYdF9S4Yr4mCfZCjdLkXC9K wuTaszJhiSLum7MM/uUQPE6CimRlDIaQ6vZxe9ekIKlbgbVrjYX/ywxfv2dxUvdbolRI PGaIpxAyi57t3lBhTEVTvGhVloGlPZcTdAeJ0vjNRI3bUX5Qkk/B6vR0MAHFU/GbHosj n7AwwGAdUbEZ63mLG7o3qZToJbdvVFL9HUtnS9JT+tdTgSOz/XMvtHmRl3l8/WLg4NOj /SY8PnhPcM6KM40amLMXd1lzMXySFioo4+5Ll/gUHeFQw5sy1BhzV/IQ+g9qYfz10Ggd +z+w== X-Gm-Message-State: ALoCoQl+8srioWQrTgWs9odcN400pPqELChOqElem31ij0BHUCZhJ0W6VTAfi+ZxgwZkQzWTcy9c X-Received: by 10.152.3.229 with SMTP id f5mr3591964laf.94.1416577476819; Fri, 21 Nov 2014 05:44:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.1 with HTTP; Fri, 21 Nov 2014 05:44:06 -0800 (PST) In-Reply-To: References: <-7425247475772590723@unknownmsgid> From: Steven Hartland Date: Fri, 21 Nov 2014 13:44:06 +0000 Message-ID: Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "stable@freebsd.org" , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 13:44:40 -0000 Not had chance to look at this I'm afraid, as I'm out at an event, but we're actually using releng/10.1 here as a cache box which is doing a between 2-8Gbps from a ZFS array so pretty high loads, with zero problems. That and not other reports of issues I'm wondering if you have either some bad data on your pool or a HW issue e.g. bad memory / processor? On 21 November 2014 10:28, Dmitry Morozovsky wrote: > Steven, colleagues, > > any news on this? I now have a bunch of cores, most from my own > experiments, > but also from daily find, all with similar sympthoms. > > On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > > > On Tue, 18 Nov 2014, Steven Hartland wrote: > > > > > > > Can u plug a usb drive in to get a dump? > > > > > > Hm, will it work over USB stack? I can try this. > > > > > > BTW: it seems some internal ZFS locking trouble exists, as trere are 3 > cases: > > > > > > pool/R/fs1 mounted as /fs1 > > > pool/R/fs2 > > > pool/R/fs3 > > > > > > tar cf - /fs1 >/dev/null works ok > > > tar cf - /fs2 >/dev/null works ok > > > rsync -avHP /fs1/ /fs2/ panics in few minutes > > > > > > will try to configure dump to USB SATA > > > > wow, it works ;) > > > > not on the first trial, but anyway, here we go: > > > > #0 doadump (textdump=1621911824) at pcpu.h:219 > > #1 0xffffffff803471d5 in db_fncall (dummy1=, > > dummy2=, dummy3=, > > dummy4=) at /usr/src/sys/ddb/db_command.c:568 > > #2 0xffffffff80346ebd in db_command (cmd_table=0x0) at > > /usr/src/sys/ddb/db_command.c:440 > > #3 0xffffffff80346c34 in db_command_loop () at > > /usr/src/sys/ddb/db_command.c:493 > > #4 0xffffffff80349580 in db_trap (type=, code=0) at > > /usr/src/sys/ddb/db_main.c:231 > > #5 0xffffffff80940cd9 in kdb_trap (type=3, code=0, tf= out>) > > at /usr/src/sys/kern/subr_kdb.c:656 > > #6 0xffffffff80ce8ca3 in trap (frame=0xfffffe0860ac6d40) at > > /usr/src/sys/amd64/amd64/trap.c:556 > > #7 0xffffffff80ccf492 in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:232 > > #8 0xffffffff8094043e in kdb_enter (why=0xffffffff80f5b27c "panic", > msg= > optimized out>) at cpufunc.h:63 > > #9 0xffffffff80908f76 in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:752 > > #10 0xffffffff80908fe3 in panic (fmt=0xffffffff8154f850 "\004") at > > /usr/src/sys/kern/kern_shutdown.c:688 > > #11 0xffffffff80b64502 in vm_fault_hold (map=, > > vaddr=, fault_type=, > > fault_flags=, m_hold=) at > > /usr/src/sys/vm/vm_fault.c:341 > > #12 0xffffffff80b62b87 in vm_fault (map=0xfffff80002000000, vaddr= > optimized out>, fault_type=1 '\001', fault_flags=128) > > at /usr/src/sys/vm/vm_fault.c:281 > > #13 0xffffffff80ce9551 in trap_pfault (frame=0xfffffe0860ac7400, > usermode=0) at > > /usr/src/sys/amd64/amd64/trap.c:752 > > #14 0xffffffff80ce8cba in trap (frame=0xfffffe0860ac7400) at > > /usr/src/sys/amd64/amd64/trap.c:440 > > #15 0xffffffff80ccf492 in calltrap () at > > /usr/src/sys/amd64/amd64/exception.S:232 > > #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, > > h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) > > at > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 > > #17 0xffffffff81b688ee in fzap_cursor_retrieve (zap=0xfffff8001676ce80, > > zc=0xfffffe0860ac77d8, za=0xfffffe0860ac76c0) > > at > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1190 > > #18 0xffffffff81b6dc97 in zap_cursor_retrieve (zc=0xfffffe0860ac77d8, > > za=0xfffffe0860ac76c0) > > at > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 > > #19 0xffffffff81ba8f16 in zfs_freebsd_readdir (ap=) > > at > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2565 > > #20 0xffffffff80e03967 in VOP_READDIR_APV (vop=, > a= > optimized out>) at vnode_if.c:1821 > > #21 0xffffffff809b1d1c in kern_getdirentries (td=0xfffff80025ff1490, > fd= > optimized out>, > > buf=0x801428000
, count= optimized > > out>, basep=0xfffffe0860ac7990, residp=0x0) > > at vnode_if.h:758 > > #22 0xffffffff809b1ad8 in sys_getdirentries (td=0xfffff801bd6ec880, > > uap=0xfffffe0860ac7a40) at /usr/src/sys/kern/vfs_syscalls.c:4030 > > #23 0xffffffff80ce9aca in amd64_syscall (td=0xfffff80025ff1490, > traced=0) at > > subr_syscall.c:134 > > #24 0xffffffff80ccf77b in Xfast_syscall () at > > /usr/src/sys/amd64/amd64/exception.S:391 > > #25 0x000000080091043a in ?? () > > > > #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, > > h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) at > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 > > 466 if (HCD_GTEQ(le->le_hash, le->le_cd, h, > cd) && > > (kgdb) p *le->le_hash > > No symbol "le" in current context. > > (kgdb) p le > > No symbol "le" in current context. > > (kgdb) p h > > $1 = 1441072784640835584 > > (kgdb) p *h > > Cannot access memory at address 0x13ffb81000000000 > > (kgdb) p cd > > $2 = 1 > > > > where now? > > > > > > > > > > > > > > > > > > On 18 Nov 2014, at 16:57, Dmitry Morozovsky > wrote: > > > > > > > > > >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > > >> > > > > >> my backup server after updrade to frest stable/10 > > > > >> > > > > >> start panicing on heavy disk load like rsync at > > > > > > > > > > Yes, it is reproducible easy and now I'm at ddb prompt with > > > > > > > > > > cpuid = 0 > > > > > KDB: stack backtrace: > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0860864d60 > > > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 > > > > > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 > > > > > panic() at panic+0x43/frame 0xfffffe0860864eb0 > > > > > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 > > > > > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 > > > > > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 > > > > > trap() at trap+0x47a/frame 0xfffffe08608653f0 > > > > > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 > > > > > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, > rbp = > > > > > 0xfffffe0860865500 --- > > > > > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame > > > > > 0xfffffe0860865500 > > > > > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame > 0xfffffe0860865570 > > > > > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame > 0xfffffe0860865600 > > > > > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame > 0xfffffe0860865840 > > > > > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 > > > > > kern_getdirentries() at kern_getdirentries+0x21c/frame > 0xfffffe0860865970 > > > > > sys_getdirentries() at sys_getdirentries+0x28/frame > 0xfffffe08608659a0 > > > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 > > > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 > > > > > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = > 0x80091043a, rsp = > > > > > 0x7fffffffb538, rbp = 0x7fffffffb560 --- > > > > > KDB: enter: panic > > > > > [ thread pid 1167 tid 100461 ] > > > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > > db> > > > > > > > > > > Can I obtain somthing useful from here? I'm afraid it's not easy > to attach > > > > > additional disk for crash dumps to this server... > > > > > > > > > > > > > > >> > > > > >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 > r274646: Tue Nov 18 > > > > >> 12:15:24 MSK 2014 > > > > >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC > amd64 > > > > >> > > > > >> > > > > >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 > > > > >> cpuid = 0 > > > > >> KDB: stack backtrace: > > > > >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 > > > > >> #1 0xffffffff8092a085 at panic+0x155 > > > > >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e > > > > >> #3 0xffffffff80b9fad7 at vm_fault+0x77 > > > > >> #4 0xffffffff80d2861c at trap_pfault+0x19c > > > > >> #5 0xffffffff80d27dea at trap+0x47a > > > > >> #6 0xffffffff80d0db92 at calltrap+0x8 > > > > >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e > > > > >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 > > > > >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 > > > > >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 > > > > >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c > > > > >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 > > > > >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 > > > > >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb > > > > >> Uptime: 1m51s > > > > >> > > > > >> Unfortunately it's ZFS only, so I have no space to white panic > dump. > > > > >> > > > > >> I'm now trying to rebuild kernel with debugger turned on, as > luckily I have > > > > >> working console@SOL... > > > > >> > > > > >> Any preliminary hints? > > > > >> > > > > >> > > > > > > > > > > -- > > > > > Sincerely, > > > > > D.Marck [DM5020, MCK-RIPE, > DM3-RIPN] > > > > > [ FreeBSD committer: > marck@FreeBSD.org ] > > > > > > ------------------------------------------------------------------------ > > > > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- > marck@rinet.ru *** > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > > > 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" > > > > > > > > > > > > > > > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 21 22:53:55 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB93DC7; Fri, 21 Nov 2014 22:53:55 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91EFE953; Fri, 21 Nov 2014 22:53:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sALMrTxF073687; Sat, 22 Nov 2014 01:53:29 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 22 Nov 2014 01:53:29 +0300 (MSK) From: Dmitry Morozovsky To: Steven Hartland Subject: Re: ZFS panic: [Re: stable/10 panic under disk load] In-Reply-To: Message-ID: References: <-7425247475772590723@unknownmsgid> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sat, 22 Nov 2014 01:53:29 +0300 (MSK) Cc: "stable@freebsd.org" , "smh@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Nov 2014 22:53:55 -0000 On Fri, 21 Nov 2014, Steven Hartland wrote: > Not had chance to look at this I'm afraid, as I'm out at an event, but > we're actually using releng/10.1 here as a cache box which is doing a > between 2-8Gbps from a ZFS array so pretty high loads, with zero problems. > > That and not other reports of issues I'm wondering if you have either some > bad data on your pool or a HW issue e.g. bad memory / processor? Hopefully not; it *may be* well as a resuly from some sporadic data corruption in the process of mass extracting -- but hey, doesn't ZFS architected to avoid data corruption at all phases? ;) At least, I think no panics should be generated, and we'll better track this down. Not in a hurry, I can mark the file systems in question unmountable for the time being and not disturb the server with frequent reboots. Thank you! > > any news on this? I now have a bunch of cores, most from my own > > experiments, > > but also from daily find, all with similar sympthoms. > > > > On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > > > On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > > > > > On Tue, 18 Nov 2014, Steven Hartland wrote: > > > > > > > > > Can u plug a usb drive in to get a dump? > > > > > > > > Hm, will it work over USB stack? I can try this. > > > > > > > > BTW: it seems some internal ZFS locking trouble exists, as trere are 3 > > cases: > > > > > > > > pool/R/fs1 mounted as /fs1 > > > > pool/R/fs2 > > > > pool/R/fs3 > > > > > > > > tar cf - /fs1 >/dev/null works ok > > > > tar cf - /fs2 >/dev/null works ok > > > > rsync -avHP /fs1/ /fs2/ panics in few minutes > > > > > > > > will try to configure dump to USB SATA > > > > > > wow, it works ;) > > > > > > not on the first trial, but anyway, here we go: > > > > > > #0 doadump (textdump=1621911824) at pcpu.h:219 > > > #1 0xffffffff803471d5 in db_fncall (dummy1=, > > > dummy2=, dummy3=, > > > dummy4=) at /usr/src/sys/ddb/db_command.c:568 > > > #2 0xffffffff80346ebd in db_command (cmd_table=0x0) at > > > /usr/src/sys/ddb/db_command.c:440 > > > #3 0xffffffff80346c34 in db_command_loop () at > > > /usr/src/sys/ddb/db_command.c:493 > > > #4 0xffffffff80349580 in db_trap (type=, code=0) at > > > /usr/src/sys/ddb/db_main.c:231 > > > #5 0xffffffff80940cd9 in kdb_trap (type=3, code=0, tf= > out>) > > > at /usr/src/sys/kern/subr_kdb.c:656 > > > #6 0xffffffff80ce8ca3 in trap (frame=0xfffffe0860ac6d40) at > > > /usr/src/sys/amd64/amd64/trap.c:556 > > > #7 0xffffffff80ccf492 in calltrap () at > > > /usr/src/sys/amd64/amd64/exception.S:232 > > > #8 0xffffffff8094043e in kdb_enter (why=0xffffffff80f5b27c "panic", > > msg= > > optimized out>) at cpufunc.h:63 > > > #9 0xffffffff80908f76 in vpanic (fmt=, ap= > > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:752 > > > #10 0xffffffff80908fe3 in panic (fmt=0xffffffff8154f850 "\004") at > > > /usr/src/sys/kern/kern_shutdown.c:688 > > > #11 0xffffffff80b64502 in vm_fault_hold (map=, > > > vaddr=, fault_type=, > > > fault_flags=, m_hold=) at > > > /usr/src/sys/vm/vm_fault.c:341 > > > #12 0xffffffff80b62b87 in vm_fault (map=0xfffff80002000000, vaddr= > > optimized out>, fault_type=1 '\001', fault_flags=128) > > > at /usr/src/sys/vm/vm_fault.c:281 > > > #13 0xffffffff80ce9551 in trap_pfault (frame=0xfffffe0860ac7400, > > usermode=0) at > > > /usr/src/sys/amd64/amd64/trap.c:752 > > > #14 0xffffffff80ce8cba in trap (frame=0xfffffe0860ac7400) at > > > /usr/src/sys/amd64/amd64/trap.c:440 > > > #15 0xffffffff80ccf492 in calltrap () at > > > /usr/src/sys/amd64/amd64/exception.S:232 > > > #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, > > > h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) > > > at > > > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 > > > #17 0xffffffff81b688ee in fzap_cursor_retrieve (zap=0xfffff8001676ce80, > > > zc=0xfffffe0860ac77d8, za=0xfffffe0860ac76c0) > > > at > > > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap.c:1190 > > > #18 0xffffffff81b6dc97 in zap_cursor_retrieve (zc=0xfffffe0860ac77d8, > > > za=0xfffffe0860ac76c0) > > > at > > > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:1290 > > > #19 0xffffffff81ba8f16 in zfs_freebsd_readdir (ap=) > > > at > > > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2565 > > > #20 0xffffffff80e03967 in VOP_READDIR_APV (vop=, > > a= > > optimized out>) at vnode_if.c:1821 > > > #21 0xffffffff809b1d1c in kern_getdirentries (td=0xfffff80025ff1490, > > fd= > > optimized out>, > > > buf=0x801428000
, count= > optimized > > > out>, basep=0xfffffe0860ac7990, residp=0x0) > > > at vnode_if.h:758 > > > #22 0xffffffff809b1ad8 in sys_getdirentries (td=0xfffff801bd6ec880, > > > uap=0xfffffe0860ac7a40) at /usr/src/sys/kern/vfs_syscalls.c:4030 > > > #23 0xffffffff80ce9aca in amd64_syscall (td=0xfffff80025ff1490, > > traced=0) at > > > subr_syscall.c:134 > > > #24 0xffffffff80ccf77b in Xfast_syscall () at > > > /usr/src/sys/amd64/amd64/exception.S:391 > > > #25 0x000000080091043a in ?? () > > > > > > #16 0xffffffff81b69d04 in zap_leaf_lookup_closest (l=0xfffff801bd6ec880, > > > h=1441072784640835584, cd=1, zeh=0xfffffe0860ac7518) at > > > > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c:466 > > > 466 if (HCD_GTEQ(le->le_hash, le->le_cd, h, > > cd) && > > > (kgdb) p *le->le_hash > > > No symbol "le" in current context. > > > (kgdb) p le > > > No symbol "le" in current context. > > > (kgdb) p h > > > $1 = 1441072784640835584 > > > (kgdb) p *h > > > Cannot access memory at address 0x13ffb81000000000 > > > (kgdb) p cd > > > $2 = 1 > > > > > > where now? > > > > > > > > > > > > > > > > > > > > > > > On 18 Nov 2014, at 16:57, Dmitry Morozovsky > > wrote: > > > > > > > > > > > >> On Tue, 18 Nov 2014, Dmitry Morozovsky wrote: > > > > > >> > > > > > >> my backup server after updrade to frest stable/10 > > > > > >> > > > > > >> start panicing on heavy disk load like rsync at > > > > > > > > > > > > Yes, it is reproducible easy and now I'm at ddb prompt with > > > > > > > > > > > > cpuid = 0 > > > > > > KDB: stack backtrace: > > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe0860864d60 > > > > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0860864e10 > > > > > > vpanic() at vpanic+0x126/frame 0xfffffe0860864e50 > > > > > > panic() at panic+0x43/frame 0xfffffe0860864eb0 > > > > > > vm_fault_hold() at vm_fault_hold+0x1932/frame 0xfffffe0860865100 > > > > > > vm_fault() at vm_fault+0x77/frame 0xfffffe0860865140 > > > > > > trap_pfault() at trap_pfault+0x201/frame 0xfffffe08608651e0 > > > > > > trap() at trap+0x47a/frame 0xfffffe08608653f0 > > > > > > calltrap() at calltrap+0x8/frame 0xfffffe08608653f0 > > > > > > --- trap 0xc, rip = 0xffffffff81b69d04, rsp = 0xfffffe08608654b0, > > rbp = > > > > > > 0xfffffe0860865500 --- > > > > > > zap_leaf_lookup_closest() at zap_leaf_lookup_closest+0xb4/frame > > > > > > 0xfffffe0860865500 > > > > > > fzap_cursor_retrieve() at fzap_cursor_retrieve+0x16e/frame > > 0xfffffe0860865570 > > > > > > zap_cursor_retrieve() at zap_cursor_retrieve+0x1f7/frame > > 0xfffffe0860865600 > > > > > > zfs_freebsd_readdir() at zfs_freebsd_readdir+0x426/frame > > 0xfffffe0860865840 > > > > > > VOP_READDIR_APV() at VOP_READDIR_APV+0xa7/frame 0xfffffe0860865870 > > > > > > kern_getdirentries() at kern_getdirentries+0x21c/frame > > 0xfffffe0860865970 > > > > > > sys_getdirentries() at sys_getdirentries+0x28/frame > > 0xfffffe08608659a0 > > > > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe0860865ab0 > > > > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0860865ab0 > > > > > > --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = > > 0x80091043a, rsp = > > > > > > 0x7fffffffb538, rbp = 0x7fffffffb560 --- > > > > > > KDB: enter: panic > > > > > > [ thread pid 1167 tid 100461 ] > > > > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > > > db> > > > > > > > > > > > > Can I obtain somthing useful from here? I'm afraid it's not easy > > to attach > > > > > > additional disk for crash dumps to this server... > > > > > > > > > > > > > > > > > >> > > > > > >> FreeBSD whale.rinet.ru 10.1-STABLE FreeBSD 10.1-STABLE #195 > > r274646: Tue Nov 18 > > > > > >> 12:15:24 MSK 2014 > > > > > >> marck@castor.rinet.ru:/usr/obj/FreeBSD/pristine/src.10/sys/GENERIC > > amd64 > > > > > >> > > > > > >> > > > > > >> panic: vm_fault: fault on nofault entry, addr: fffffe001805b000 > > > > > >> cpuid = 0 > > > > > >> KDB: stack backtrace: > > > > > >> #0 0xffffffff80964fa0 at kdb_backtrace+0x60 > > > > > >> #1 0xffffffff8092a085 at panic+0x155 > > > > > >> #2 0xffffffff80ba168e at vm_fault_hold+0x1b6e > > > > > >> #3 0xffffffff80b9fad7 at vm_fault+0x77 > > > > > >> #4 0xffffffff80d2861c at trap_pfault+0x19c > > > > > >> #5 0xffffffff80d27dea at trap+0x47a > > > > > >> #6 0xffffffff80d0db92 at calltrap+0x8 > > > > > >> #7 0xffffffff819df8ee at fzap_cursor_retrieve+0x16e > > > > > >> #8 0xffffffff819e4c97 at zap_cursor_retrieve+0x1f7 > > > > > >> #9 0xffffffff81a1fed6 at zfs_freebsd_readdir+0x426 > > > > > >> #10 0xffffffff80e456b7 at VOP_READDIR_APV+0xa7 > > > > > >> #11 0xffffffff809d68cc at kern_getdirentries+0x21c > > > > > >> #12 0xffffffff809d6688 at sys_getdirentries+0x28 > > > > > >> #13 0xffffffff80d28da1 at amd64_syscall+0x351 > > > > > >> #14 0xffffffff80d0de7b at Xfast_syscall+0xfb > > > > > >> Uptime: 1m51s > > > > > >> > > > > > >> Unfortunately it's ZFS only, so I have no space to white panic > > dump. > > > > > >> > > > > > >> I'm now trying to rebuild kernel with debugger turned on, as > > luckily I have > > > > > >> working console@SOL... > > > > > >> > > > > > >> Any preliminary hints? > > > > > >> > > > > > >> > > > > > > > > > > > > -- > > > > > > Sincerely, > > > > > > D.Marck [DM5020, MCK-RIPE, > > DM3-RIPN] > > > > > > [ FreeBSD committer: > > marck@FreeBSD.org ] > > > > > > > > ------------------------------------------------------------------------ > > > > > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- > > marck@rinet.ru *** > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > 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" > > > > > > > > > > > > > > > > > > > > > > > -- > > Sincerely, > > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > [ FreeBSD committer: marck@FreeBSD.org ] > > ------------------------------------------------------------------------ > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > > ------------------------------------------------------------------------ > > > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sat Nov 22 17:17:38 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8D77413 for ; Sat, 22 Nov 2014 17:17:38 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88BD0A92 for ; Sat, 22 Nov 2014 17:17:38 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id k14so9253823wgh.37 for ; Sat, 22 Nov 2014 09:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=PSB15MkeIbLsrB06Rmu80YTxtQKIw4xe1DyBujEzQB8=; b=UQGiwn9trlnssPry6Wm9E6C/QVNjVp+uStO1Z3kNjTDTnICz7ZuDom5f/gHUOxX+gv 5/eR0cBnHKxLUKfoN9kGmz0MkcvOl2GlxWG+IeECyndc3NSTu+Z/MwgavAF4hgki3Jq4 reKZZwHyNL2oxNwhuYWd3JKh1QLRSOfIOAWOiAXf5yNVGUMXHlgm18NvLTEq+P+YTYvE e2SZ8pv2kKIgUVpORIyxhp4meNuviCRJ4A9AkQgwwifF9mdZqxMCn3pgovS9cVv/G0Tx H7OeeXW2z4iYm+Z+iHsCGBcItEiYiDhHfApxNeBe8FSYjUgIgFc1BmTwoxTdFWkjXGV7 8DLQ== X-Received: by 10.180.211.108 with SMTP id nb12mr7265611wic.76.1416676656805; Sat, 22 Nov 2014 09:17:36 -0800 (PST) Received: from localhost (p5B2FC451.dip0.t-ipconnect.de. [91.47.196.81]) by mx.google.com with ESMTPSA id ge17sm4024163wic.0.2014.11.22.09.17.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Nov 2014 09:17:36 -0800 (PST) Sender: Thomas Zander Date: Sat, 22 Nov 2014 18:17:34 +0100 From: Thomas Zander To: stable@freebsd.org Subject: ath(4) device timeout -> reboot necessary Message-ID: <20141122171734.GA4600@marvin2011.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-KeyID: 0xC85996CD X-PGP-URL: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8DD48929C85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 17:17:38 -0000 Hi, regularly[1] I get those on my workstation: Nov 22 10:52:15 marvin2011 kernel: ath0: device timeout Nov 22 13:31:43 marvin2011 kernel: ath0: device timeout Nov 22 13:52:54 marvin2011 kernel: ath0: device timeout Nov 22 16:50:05 marvin2011 kernel: ath0: device timeout Weren't there logs, most of the time I would not even notice, but sometimes the machine loses connection to the AP, and when that happens, I first try to disable wpa_supplicant and restart the interface. Rarely[2] this works, but most of the time, this happens: Nov 22 16:53:37 marvin2011 kernel: wlan0: link state changed to DOWN Nov 22 16:53:37 marvin2011 dhclient[339]: connection closed Nov 22 16:53:37 marvin2011 dhclient[339]: exiting. Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Device not configured Nov 22 16:53:37 marvin2011 last message repeated 3 times Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=25, val=0, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=95, val=208, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=17, val=0, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=95, val=208, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=17, val=0, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=16, val=1, arg_len=0]: Device not configured Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: wlan0: CTRL-EVENT-TERMINATING Nov 22 16:53:37 marvin2011 riggs: /etc/rc.d/netif: WARNING: wlan0 does not exist. Skipped. Nov 22 16:54:27 marvin2011 kernel: wlan0: Ethernet address: Nov 22 16:54:27 marvin2011 devd: Executing '/etc/pccard_ether wlan0 start' Nov 22 16:54:27 marvin2011 wpa_supplicant[92697]: Successfully initialized wpa_supplicant Nov 22 16:54:27 marvin2011 wpa_supplicant[92712]: Successfully initialized wpa_supplicant Nov 22 16:54:27 marvin2011 dhclient[92732]: dhclient already running, pid: 92731. Nov 22 16:54:27 marvin2011 dhclient[92732]: exiting. Nov 22 16:54:27 marvin2011 riggs: /etc/rc.d/dhclient: WARNING: failed to start dhclient Nov 22 16:54:27 marvin2011 wpa_supplicant[92714]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Nov 22 16:54:27 marvin2011 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations Nov 22 16:54:27 marvin2011 kernel: ath0: ath_reset_grablock: warning, recursive reset path! Nov 22 16:54:27 marvin2011 kernel: ath0: oath_reset: concurrent reset! Danger! Nov 22 16:54:27 marvin2011 wpa_supplicant[92714]: wlan0: Failed to initiate AP scan Nov 22 16:54:28 marvin2011 wpa_supplicant[92713]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Nov 22 16:54:28 marvin2011 wpa_supplicant[92713]: wlan0: Failed to initiate AP scan Nov 22 16:54:29 marvin2011 wpa_supplicant[92714]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Nov 22 16:54:29 marvin2011 wpa_supplicant[92714]: wlan0: Failed to initiate AP scan After this, the console gets flooded with the same error messages from ath(4) (grablog, recursive reset, danger) and wpa_supplicant over and over. Machine is 10.1-STABLE amd64, this is the dmesg output from the wlan adapter: ath0: mem 0xf7c00000-0xf7c0ffff irq 16 at device 0.0 on pci4 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 So far, I have been unable to find a solution other than rebooting the machine, and I am looking for better options. The favourite option, obviously, is a patch that resolves it, but recommending an adapter that just works[tm] out of the box on 10.1 is acceptable as well, as long as - it is PCIe, and - currently, as of today, available at one of the usual dealers in Germany, e.g. amazon.de, mindfactory, etc. Of course I am happy to do whatever I can to debug the problem, but in lack of expert knowledge on wlan drivers, I'd need some help here. Best regards Riggs [1] statistically about once every three hours [2] roughly in 10% of the cases From owner-freebsd-stable@FreeBSD.ORG Sat Nov 22 17:26:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AAC0780 for ; Sat, 22 Nov 2014 17:26:20 +0000 (UTC) Received: from nm35-vm3.bullet.mail.bf1.yahoo.com (nm35-vm3.bullet.mail.bf1.yahoo.com [72.30.238.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F2AEBA6 for ; Sat, 22 Nov 2014 17:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s2048; t=1416677000; bh=qrn4lzRKdkb83aK1GOuiFdq+Qo+OcEl/luF96i0Xtvs=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=WdBn9LpmDV1qfdfgEjwse5Eglf2ehBAumTZ3k6tdBUk04/rj39aWds3WZY1Rgjn3zJWmmuMFXjZjYTrcJZRPyMhizSaLINOTCwDY0hgkk4VyYasPmOAd5WfmJrsz382Q0aJrqJgfIuShTIsvaB3EUO5KFY3NkJDFxiJv+ktGSE8yZlVWG6k72PV6X/CIS/OLiMoRXL+rKTI2PqCBvyOtsFE6X0jYvlNjn/ExyK1h/aF2JRBGwp1ihtSxlet0jUuJTuR7ft72Ijo9oemv0RFTroFqnylUdFlg9MDRyBX7JcufdAd7+p+DKuhbljGZKAbGGV5ElyYCAFkkqGSLr+qVNQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.br; b=cnMFIPIe3XEtsWZG1rjqQXRdff3iE998szh2rJBcelGigPpfke/QIwSdcEmi5zjn1noRfCwAtLcCzicuZYGI8DUXPJVj3/BBTTqUllnqJTQuhFkqZYHEhIRm6rHZjDh6lhn/3MWJ3WFE8UX8Q/Pt5TIJcr0oDyhtL2CJZRP6Kx+4Y/BNRsFsidCj9bKPnt2IhN9U8osXwOPpfRnHTYiB0ZN+EWa/CH4eXrAmU/YxdDR63FiF7qVB1OWDftD8gE60MudFBWXDbCoRpKBPdPQ27NaKzQp95FA1EwsziC1ZJAHklNnG8wRAfnCpEakLPWwtQ/I2jtBuZn+FdWakdPc7CQ==; Received: from [98.139.214.32] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 22 Nov 2014 17:23:20 -0000 Received: from [68.142.230.71] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Nov 2014 17:23:20 -0000 Received: from [127.0.0.1] by smtp228.mail.bf1.yahoo.com with NNFMP; 22 Nov 2014 17:23:20 -0000 X-Yahoo-Newman-Id: 524574.96185.bm@smtp228.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: anRhLIkVM1mg9aldhc0TEPlShDWchv6r0C1NgvNsY_qDRxp Gs5.bD9v5jA9zvPtiwY6bGKFANAj83d9b4eYrPU4_T_SRe.KNRQLem3eXnbD zasjGrN1cx.0mvqdQpTPaN.VV.Ciz3sphY0_77HXlX1natmduc6cjA_iAacb sq4hqVTmYCqMtfAIvMvNu1wYqh2vKDeeIQkiewupAH4gT7yV_N39wqVP9uHS CdcDxHuYGCeqFMvNmcNRLhEIYeyNHbpKitRgShjC6.NZYOZ5DUdqL3kTzDKn h9ZDTRUJZEnv.jBdYrgY5PJp0BwItzMEKX8NEcrsnPpp1942sI2urHDPGI7g Ip3gJsHX_uyGtMcH.UuEXQzA09ndUg_Hexyozs6IfdQUXzdlCXN7aTraN4ho 8pLckMv6TsLQucMqX0f5tmhkxJ0oy0tyUR1dsnKbI2_9lRqMmmfHORgQJjkG 9RAkRHReLGMfKmiYfjyMN2uMwRT75xqxrxU5PjNGclZ8CWFgGDtJZLzTjBSg ihSuuyk9scT50I4Peogs9epoD211fpW9yWKQ3XFqfcYbS418aEMRYut4iMPK 8QMXwJnGNt7iw9FE- X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- Message-ID: <5470C695.3040204@yahoo.com.br> Date: Sat, 22 Nov 2014 15:23:33 -0200 From: Danilo Egea Gondolfo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ath(4) device timeout -> reboot necessary References: <20141122171734.GA4600@marvin2011.fritz.box> In-Reply-To: <20141122171734.GA4600@marvin2011.fritz.box> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 17:26:20 -0000 On 11/22/14 15:17, Thomas Zander wrote: > Hi, > > regularly[1] I get those on my workstation: > > Nov 22 10:52:15 marvin2011 kernel: ath0: device timeout > Nov 22 13:31:43 marvin2011 kernel: ath0: device timeout > Nov 22 13:52:54 marvin2011 kernel: ath0: device timeout > Nov 22 16:50:05 marvin2011 kernel: ath0: device timeout > > Weren't there logs, most of the time I would not even notice, but > sometimes the machine loses connection to the AP, and when that > happens, I first try to disable wpa_supplicant and restart the > interface. Rarely[2] this works, but most of the time, this happens: > > Nov 22 16:53:37 marvin2011 kernel: wlan0: link state changed to DOWN > Nov 22 16:53:37 marvin2011 dhclient[339]: connection closed > Nov 22 16:53:37 marvin2011 dhclient[339]: exiting. > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Device not configured > Nov 22 16:53:37 marvin2011 last message repeated 3 times > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=25, val=0, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=95, val=208, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=17, val=0, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=95, val=208, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=17, val=0, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=16, val=1, arg_len=0]: Device not configured > Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: wlan0: CTRL-EVENT-TERMINATING > Nov 22 16:53:37 marvin2011 riggs: /etc/rc.d/netif: WARNING: wlan0 does not exist. Skipped. > Nov 22 16:54:27 marvin2011 kernel: wlan0: Ethernet address: > Nov 22 16:54:27 marvin2011 devd: Executing '/etc/pccard_ether wlan0 start' > Nov 22 16:54:27 marvin2011 wpa_supplicant[92697]: Successfully initialized wpa_supplicant > Nov 22 16:54:27 marvin2011 wpa_supplicant[92712]: Successfully initialized wpa_supplicant > Nov 22 16:54:27 marvin2011 dhclient[92732]: dhclient already running, pid: 92731. > Nov 22 16:54:27 marvin2011 dhclient[92732]: exiting. > Nov 22 16:54:27 marvin2011 riggs: /etc/rc.d/dhclient: WARNING: failed to start dhclient > Nov 22 16:54:27 marvin2011 wpa_supplicant[92714]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress > Nov 22 16:54:27 marvin2011 kernel: ath0: ath_reset_grablock: didn't finish after 10 iterations > Nov 22 16:54:27 marvin2011 kernel: ath0: ath_reset_grablock: warning, recursive reset path! > Nov 22 16:54:27 marvin2011 kernel: ath0: oath_reset: concurrent reset! Danger! > Nov 22 16:54:27 marvin2011 wpa_supplicant[92714]: wlan0: Failed to initiate AP scan > Nov 22 16:54:28 marvin2011 wpa_supplicant[92713]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress > Nov 22 16:54:28 marvin2011 wpa_supplicant[92713]: wlan0: Failed to initiate AP scan > Nov 22 16:54:29 marvin2011 wpa_supplicant[92714]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress > Nov 22 16:54:29 marvin2011 wpa_supplicant[92714]: wlan0: Failed to initiate AP scan > > > After this, the console gets flooded with the same error messages from > ath(4) (grablog, recursive reset, danger) and wpa_supplicant over and > over. > > Machine is 10.1-STABLE amd64, this is the dmesg output from the wlan > adapter: > ath0: mem 0xf7c00000-0xf7c0ffff irq 16 at device 0.0 on pci4 > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 2 RX streams; 2 TX streams > ath0: AR9287 mac 384.2 RF5133 phy 15.15 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > So far, I have been unable to find a solution other than > rebooting the machine, and I am looking for better options. > > The favourite option, obviously, is a patch that resolves it, but > recommending an adapter that just works[tm] out of the box on 10.1 is > acceptable as well, as long as > - it is PCIe, and > - currently, as of today, available at one of the usual dealers in > Germany, e.g. amazon.de, mindfactory, etc. > > Of course I am happy to do whatever I can to debug the problem, but in > lack of expert knowledge on wlan drivers, I'd need some help here. > > Best regards > Riggs > > [1] statistically about once every three hours > [2] roughly in 10% of the cases > _______________________________________________ > 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" > +1 My card is a AR9285 and I'm running HEAD (274171). From owner-freebsd-stable@FreeBSD.ORG Sat Nov 22 18:11:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DDC43C8 for ; Sat, 22 Nov 2014 18:11:51 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3644986 for ; Sat, 22 Nov 2014 18:11:51 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id ex7so2127815wid.9 for ; Sat, 22 Nov 2014 10:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tgd/8cBLzziaLcGps1i0yQxx+zLePLGd4xJ9q7o6dl0=; b=nAEDJt6y1wDfLNsAJJQVh0Qjyiozo8P7j0mJvYe/38Fw8SFd1svRQh7ihIukOcXtlg MoSa4ewO4sd/XiP6UfsuV6Dr0HeTjkonhXXSgmXjsRMvFTDtKsskcFNyc3K1NDx7Xu+O Fz1ZVV6oDWbgha6/okl/qpV0HdJiEOjdz9aK/dD34PdtBWZLiZBKz+K7VKrtSTrzAAyf vyOUk5num742xFwv6RjbaBwrXU5AoUir9ePg93ckPWXWdYpONV5LAFoJt5WrQui59MLo NSXmq34EbykZ9aEfAYnxCw1rSe1QHBQnRSI8lKtl2k9vyYmdnoTnuITZPrqiNxLmwT/w q8RA== MIME-Version: 1.0 X-Received: by 10.180.99.105 with SMTP id ep9mr7540667wib.26.1416679909574; Sat, 22 Nov 2014 10:11:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 22 Nov 2014 10:11:49 -0800 (PST) In-Reply-To: <5470C695.3040204@yahoo.com.br> References: <20141122171734.GA4600@marvin2011.fritz.box> <5470C695.3040204@yahoo.com.br> Date: Sat, 22 Nov 2014 10:11:49 -0800 X-Google-Sender-Auth: yfpgEnO13X7KmvOwoAz14LwVECk Message-ID: Subject: Re: ath(4) device timeout -> reboot necessary From: Adrian Chadd To: Danilo Egea Gondolfo Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 18:11:51 -0000 sniffle! Try setting sysctl dev.ath.0.hal.force_full_reset=1 But the reason the AR9287 is going deaf is still unknown. In station mode we detect it by seeing missed beacons and doing a hardware reset. In AP mode we don't have that; we just see it failing to do noise floor calibration and we never hear any frames. We just need to schedule a full hardware reset if the noise floor calibration fails. There are also issues with wpa_supplicant being run more than once at a time due to issues with the rc script side of things and it's confusing the wifi drivers. I haven't really looked into it in that much detail - I was hoping the RC scripts would be fixed, but I'm going to have to fix the driver to at least not confuse the hardware. (Yes, we have to fix the "running multiple copies of wpa_supplicant - as it's going to mess things up no matter what we do.) -adrian On 22 November 2014 at 09:23, Danilo Egea Gondolfo wrote: > > On 11/22/14 15:17, Thomas Zander wrote: >> >> Hi, >> >> regularly[1] I get those on my workstation: >> >> Nov 22 10:52:15 marvin2011 kernel: ath0: device timeout >> Nov 22 13:31:43 marvin2011 kernel: ath0: device timeout >> Nov 22 13:52:54 marvin2011 kernel: ath0: device timeout >> Nov 22 16:50:05 marvin2011 kernel: ath0: device timeout >> >> Weren't there logs, most of the time I would not even notice, but >> sometimes the machine loses connection to the AP, and when that >> happens, I first try to disable wpa_supplicant and restart the >> interface. Rarely[2] this works, but most of the time, this happens: >> >> Nov 22 16:53:37 marvin2011 kernel: wlan0: link state changed to DOWN >> Nov 22 16:53:37 marvin2011 dhclient[339]: connection closed >> Nov 22 16:53:37 marvin2011 dhclient[339]: exiting. >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=20, >> val=0, arg_len=7]: Device not configured >> Nov 22 16:53:37 marvin2011 last message repeated 3 times >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=25, >> val=0, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=95, >> val=208, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=17, >> val=0, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=26, >> val=0, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=95, >> val=208, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=17, >> val=0, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=26, >> val=0, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: ioctl[SIOCS80211, op=16, >> val=1, arg_len=0]: Device not configured >> Nov 22 16:53:37 marvin2011 wpa_supplicant[327]: wlan0: >> CTRL-EVENT-TERMINATING >> Nov 22 16:53:37 marvin2011 riggs: /etc/rc.d/netif: WARNING: wlan0 does not >> exist. Skipped. >> Nov 22 16:54:27 marvin2011 kernel: wlan0: Ethernet address: >> Nov 22 16:54:27 marvin2011 devd: Executing '/etc/pccard_ether wlan0 start' >> Nov 22 16:54:27 marvin2011 wpa_supplicant[92697]: Successfully initialized >> wpa_supplicant >> Nov 22 16:54:27 marvin2011 wpa_supplicant[92712]: Successfully initialized >> wpa_supplicant >> Nov 22 16:54:27 marvin2011 dhclient[92732]: dhclient already running, pid: >> 92731. >> Nov 22 16:54:27 marvin2011 dhclient[92732]: exiting. >> Nov 22 16:54:27 marvin2011 riggs: /etc/rc.d/dhclient: WARNING: failed to >> start dhclient >> Nov 22 16:54:27 marvin2011 wpa_supplicant[92714]: ioctl[SIOCS80211, >> op=103, val=0, arg_len=128]: Operation now in progress >> Nov 22 16:54:27 marvin2011 kernel: ath0: ath_reset_grablock: didn't finish >> after 10 iterations >> Nov 22 16:54:27 marvin2011 kernel: ath0: ath_reset_grablock: warning, >> recursive reset path! >> Nov 22 16:54:27 marvin2011 kernel: ath0: oath_reset: concurrent reset! >> Danger! >> Nov 22 16:54:27 marvin2011 wpa_supplicant[92714]: wlan0: Failed to >> initiate AP scan >> Nov 22 16:54:28 marvin2011 wpa_supplicant[92713]: ioctl[SIOCS80211, >> op=103, val=0, arg_len=128]: Operation now in progress >> Nov 22 16:54:28 marvin2011 wpa_supplicant[92713]: wlan0: Failed to >> initiate AP scan >> Nov 22 16:54:29 marvin2011 wpa_supplicant[92714]: ioctl[SIOCS80211, >> op=103, val=0, arg_len=128]: Operation now in progress >> Nov 22 16:54:29 marvin2011 wpa_supplicant[92714]: wlan0: Failed to >> initiate AP scan >> >> >> After this, the console gets flooded with the same error messages from >> ath(4) (grablog, recursive reset, danger) and wpa_supplicant over and >> over. >> >> Machine is 10.1-STABLE amd64, this is the dmesg output from the wlan >> adapter: >> ath0: mem 0xf7c00000-0xf7c0ffff irq 16 at device 0.0 on >> pci4 >> ath0: [HT] enabling HT modes >> ath0: [HT] enabling short-GI in 20MHz mode >> ath0: [HT] 1 stream STBC receive enabled >> ath0: [HT] 1 stream STBC transmit enabled >> ath0: [HT] 2 RX streams; 2 TX streams >> ath0: AR9287 mac 384.2 RF5133 phy 15.15 >> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> >> So far, I have been unable to find a solution other than >> rebooting the machine, and I am looking for better options. >> >> The favourite option, obviously, is a patch that resolves it, but >> recommending an adapter that just works[tm] out of the box on 10.1 is >> acceptable as well, as long as >> - it is PCIe, and >> - currently, as of today, available at one of the usual dealers in >> Germany, e.g. amazon.de, mindfactory, etc. >> >> Of course I am happy to do whatever I can to debug the problem, but in >> lack of expert knowledge on wlan drivers, I'd need some help here. >> >> Best regards >> Riggs >> >> [1] statistically about once every three hours >> [2] roughly in 10% of the cases >> _______________________________________________ >> 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" >> > +1 > > My card is a AR9285 and I'm running HEAD (274171). > > _______________________________________________ > 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 Nov 22 21:49:47 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 835BABCD; Sat, 22 Nov 2014 21:49:47 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05B118FA; Sat, 22 Nov 2014 21:49:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id sAMLY6xk088902; Sun, 23 Nov 2014 00:35:06 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 23 Nov 2014 00:34:06 +0300 (MSK) From: Dmitry Morozovsky To: des@FreeBSD.org Subject: /bin/freebsd-version does not get rebuilt in NO_CLEAN build: Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sun, 23 Nov 2014 00:35:06 +0300 (MSK) Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 21:49:47 -0000 Dear Dag-Erling, colleagues, I'm usually using -DNO_CLEAN builds including upgrades; however, it turns out that freebsd-version utility does not depend really on newvers.sh, despite it is included in Makefile dependencies: after upgrading from 1106 to 1121: marck@hamster:/usr/src/bin/freebsd-version> l /boot/*/kernel -r-xr-xr-x 1 root wheel 21165281 Nov 21 13:31 /boot/GENERIC/kernel* -r-xr-xr-x 1 root wheel 8386544 Nov 6 12:33 /boot/kernel.old/kernel* -r-xr-xr-x 1 root wheel 8396264 Nov 21 13:25 /boot/kernel/kernel* I still got marck@hamster:/usr/src/bin/freebsd-version> freebsd-version -ku 10.1-STABLE 10.1-PRERELEASE while script itself had been reinstalled: marck@hamster:/usr/src/bin/freebsd-version> l /bin/freebsd-version -r-xr-xr-x 1 root wheel 3197 Nov 21 13:38 /bin/freebsd-version* but its content did not regenerated: marck@hamster:/usr/src/bin/freebsd-version> grep -w BRANCH ../../sys/conf/newvers.sh BRANCH="STABLE" BRANCH=${BRANCH_OVERRIDE} RELEASE="${REVISION}-${BRANCH}" marck@hamster:/usr/src/bin/freebsd-version> grep USERLAND /bin/freebsd-version USERLAND_VERSION="10.1-PRERELEASE" echo $USERLAND_VERSION marck@hamster:/usr/src/bin/freebsd-version> l /usr/obj/usr/src/bin/freebsd-version/freebsd-version -rwxrwxr-x 1 marck wheel 3197 Sep 7 23:21 /usr/obj/usr/src/bin/freebsd-version/freebsd-version* -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sat Nov 22 22:21:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAD7C664; Sat, 22 Nov 2014 22:21:15 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EB2FC35; Sat, 22 Nov 2014 22:21:15 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gf13so6040912lab.13 for ; Sat, 22 Nov 2014 14:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=a5OyK/de1Cdt5Zj1DYhWFKS7M7x1bwVZlr8phFSPGF0=; b=hkqdWKYmovyfDcRusALvdHv8aHWW+AozXM3bNhLV8IrTBubDO6miVze0K6nwG2wxri /C5bkF8+MS1YTvo4VqpLkHBMuYHoC1ynDlUiAXb8P9RQ0oA6LxUbJZWDpWYbOXGS/gWw iE1HdxD5HKVJJ05Cb3NcGs/UR5NBzWBEvU+zLiy81llJ7UuAO0D3cBD7hMRflw266r/z Tt6/FVFrfTM4/HPXe7X/D5QwKgJRQo0gc3hwP4vLU6a7LkOW0CKmPna8XX7wUJJzHRlh OYTxzdr/aNt7djVdF0xePy4qB1K1nlLIZMrTq5197KxOkhtLwCdsh2ZDESaK6C/QFIYH jyYg== MIME-Version: 1.0 X-Received: by 10.152.7.193 with SMTP id l1mr12418422laa.57.1416694873566; Sat, 22 Nov 2014 14:21:13 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sat, 22 Nov 2014 14:21:13 -0800 (PST) Date: Sat, 22 Nov 2014 14:21:13 -0800 X-Google-Sender-Auth: kVaE_84ItKF9AHXwr4LllFJLFqA Message-ID: Subject: Call for Help: Flame Graphs and Continuous Integration From: Craig Rodrigues To: freebsd-current Current , FreeBSD stable , freebsd-python@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Nov 2014 22:21:16 -0000 FYI: https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/000667.html Please send follow-ups to freebsd-testing@FreeBSD.org -- Craig