From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 00:13:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 54300480 for ; Sun, 24 Feb 2013 00:13:09 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 24371B4E for ; Sun, 24 Feb 2013 00:13:09 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 3rbB1l00B0EPchoA10D8NZ; Sun, 24 Feb 2013 00:13:08 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id 40D71l00R1t3BNj8M0D8NT; Sun, 24 Feb 2013 00:13:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BD34A73A31; Sat, 23 Feb 2013 16:13:07 -0800 (PST) Date: Sat, 23 Feb 2013 16:13:07 -0800 From: Jeremy Chadwick To: Michael BlackHeart Subject: Re: Old ICH7 SATA-2 question Message-ID: <20130224001307.GA43436@icarus.home.lan> References: <20130223211932.GA41809@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361664788; bh=LkXew1ac7JdaqMoqeh0szjo+OlcwIFC/rlqZe0x66og=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=JTxi9OtMDrq08ZV53q2+lW2iib7YTaZuUAH0gL1v06RLcmnVanx0C1JxU3MeHuI5s Q74WVDoXx2CgBA8WUNrEapll+RNlxHWTzXdI7GrHslzDy5kFQhSRgC6JqUN+CuP/V4 Uo0rulbJS5+h6SPHc3P2OOOhbbzvsq84Sb6qzEg1Ekk4cGNYySlIQ11mHP4lfev8pO mSTVagu0ZpjQzDs/anTtI4Hn9ZTwrPY2cFW1C6kYyt5ReojNd0SN/juip+elsioMTH kKFQ/4mq35LMTMclEJtqgcMy7OJZUs53fhB1JCWaWZDsjEPul1WwJoXTmn1HtgWs2/ zoWn63qV7cOtw== Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 00:13:09 -0000 On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: > 2013/2/24 Jeremy Chadwick : > > {snipping irrelevant stuff and fixing formatting} > > atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'N10/ICH7 Family SATA IDE Controller' > > {snip} I had written up a significantly longer reply to this Email, but once I finished and went back reviewing the information provided, my memory recalled having this exact conversation some time ago. After some extensive digging, I found it -- circa late 2008: http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html The result of this conversation was that FreeBSD at the time -- this would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: ata_chipset.c (part of the classic ata(4) driver) was misidentifying the different revisions of ICH7 and therefore limiting controller capacities incorrectly. Possibly a regression has been introduced as a result of the ATA-via-CAM migration (now the default), which uses a completely different set of code. All the PCI IDs shown (particularly class and chip) play a huge role in this. I will try to review the relevant kernel bits to see if that's the case today. I may have to review the Linux kernel code for a comparison as well; sigh. While I fully believe mistakes/bugs/regressions should be fixed, I'm not sure how much time/effort should be put into this one. The ICH7 was RTM'd in early 2007, and most people using ICH7 controllers that lack AHCI are probably not going to be using disks that can exceed SATA150 interface speed. If there are people out there using, for example, SSDs on an ICH7 in non-AHCI mode, it would be good to know and get "pciconf -lvbc" output (specifically the entry for their ATA/SATA controller). But as with all publicly released operating systems, most Requests For Feedback are ignored, things are then changed, and only afterwards do people crawl out of their hobbit holes and speak up. :-) > And can you recommend any good HDD performance test? "diskinfo -t" is your best choice. But none of your disks (even the WD20EARX) are going to reach throughput rates that exceed SATA150 interface speed. You would need an SSD or similar device to exceed it. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 01:36:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E210EBD7 for ; Sun, 24 Feb 2013 01:36:43 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id A5C1ADB2 for ; Sun, 24 Feb 2013 01:36:42 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 12014637 for freebsd-stable@freebsd.org; Sat, 23 Feb 2013 18:36:36 -0600 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Sat, 23 Feb 2013 18:36:36 -0600 Message-ID: In-Reply-To: References: <20130123144050.GG51786@e-Gitt.NET> <20130125092723.GC79995@e-Gitt.NET> <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 01:36:43 -0000 Hello all, I've believe I've made just about all of the progress optimizing svnup as I can and I've just submitted it as a new port. With my ~ 350kb/s DSL connection, it now takes just under 30 minutes to download a fresh base/releng/8.3 tree using svnup (Subversion's svn takes approximately 12 minutes). Incremental updates, such as tracking one of the stable branches takes only 2-3 minutes. For anyone that wants to preview the port before it gets added to the ports tree (assuming I got the send-pr correct), the tarball is located at: http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz Please let me know if you find any issues. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 01:56:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E479E57 for ; Sun, 24 Feb 2013 01:56:32 +0000 (UTC) (envelope-from prvs=17673ed9fb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id E0ABAE30 for ; Sun, 24 Feb 2013 01:56:31 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002370695.msg for ; Sun, 24 Feb 2013 01:56:28 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 24 Feb 2013 01:56:28 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17673ed9fb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <91D7CC6D816644C68B49191192DD9A98@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" , "Michael BlackHeart" References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> Subject: Re: Old ICH7 SATA-2 question Date: Sun, 24 Feb 2013 01:56:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 01:56:32 -0000 ----- Original Message ----- From: "Jeremy Chadwick" > On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: >> 2013/2/24 Jeremy Chadwick : >> >> {snipping irrelevant stuff and fixing formatting} >> >> atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'N10/ICH7 Family SATA IDE Controller' >> >> {snip} > > I had written up a significantly longer reply to this Email, but once I > finished and went back reviewing the information provided, my memory > recalled having this exact conversation some time ago. After some > extensive digging, I found it -- circa late 2008: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html > > The result of this conversation was that FreeBSD at the time -- this > would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: > ata_chipset.c (part of the classic ata(4) driver) was misidentifying the > different revisions of ICH7 and therefore limiting controller capacities > incorrectly. > > Possibly a regression has been introduced as a result of the ATA-via-CAM > migration (now the default), which uses a completely different set of > code. pciconf:- atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 The PCI ID's listed aren't AHCI so are using legacy ata not ahci, the two devices listed are:- { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, { ATA_I82801GB_S1, 0, INTEL_ICH7, 0, ATA_SA300, "ICH7" }, Boot details:- atapci0: port.. ata0: at channel 0 on atapci0 atapci1: port... ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 Then your disks:- ada3 at ata2 bus 0 scbus1 target 1 lun 0 ada3: ATA-8 SATA 3.x device So your disks are in theory connected to a sata 2 compatible controller which is being correctly identified. You might want to try a verbose boot to see if that gives any information. Also check your bios to see if it has an AHCI mode for the controller and try that as its currently running in legacy. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 02:08:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F1A5354 for ; Sun, 24 Feb 2013 02:08:01 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id DE3FAE77 for ; Sun, 24 Feb 2013 02:08:00 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 41iy1l0011ZMdJ4AC280wJ; Sun, 24 Feb 2013 02:08:00 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta16.emeryville.ca.mail.comcast.net with comcast id 427z1l00E1t3BNj8c27zV7; Sun, 24 Feb 2013 02:07:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2171F73A31; Sat, 23 Feb 2013 18:07:59 -0800 (PST) Date: Sat, 23 Feb 2013 18:07:59 -0800 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Old ICH7 SATA-2 question Message-ID: <20130224020759.GA46759@icarus.home.lan> References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> <91D7CC6D816644C68B49191192DD9A98@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91D7CC6D816644C68B49191192DD9A98@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361671680; bh=AVAuKapcNxOwcDsqSB5X2GDrFtdm+2lXXl0mXvBryDM=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=Peoz7OExD2Oesm2/HwDd3TruITAig2Ays7+FlVn4Bayqubk96iU82MF5mzuTbwbvH fmQGVZK2W+3S2KCdnNT7NlVbonHnooaykjJOzUwzfT9tN6M6wQ8xLAFDV3LwucYEyJ NyQjYGBGIDNHzDN4t9tel6m56p11qHr2GT+4ViZJQ1mnTgyMApcxahmb6HOOrJIAS+ lVtmPJH3k5g7dfdQrYjXI8hu2yyXcltsI1uN066kPtuxDDin+VdbpU2abNEvCcJcdS o+5ExFAQDKyEE914HQFi4yt+PM6ulNeug+Vr7x/VA7nOWHiBhnfdBoyDO8Z3kE9zVp ZPSrgqq2ABYjg== Cc: freebsd-stable , Michael BlackHeart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 02:08:01 -0000 On Sun, Feb 24, 2013 at 01:56:46AM -0000, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > > >On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: > >>2013/2/24 Jeremy Chadwick : > >> > >>{snipping irrelevant stuff and fixing formatting} > >> > >>atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'N10/ICH7 Family SATA IDE Controller' > >> > >>{snip} > > > >I had written up a significantly longer reply to this Email, but once I > >finished and went back reviewing the information provided, my memory > >recalled having this exact conversation some time ago. After some > >extensive digging, I found it -- circa late 2008: > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html > > > >The result of this conversation was that FreeBSD at the time -- this > >would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: > >ata_chipset.c (part of the classic ata(4) driver) was misidentifying the > >different revisions of ICH7 and therefore limiting controller capacities > >incorrectly. > > > >Possibly a regression has been introduced as a result of the ATA-via-CAM > >migration (now the default), which uses a completely different set of > >code. > > pciconf:- > atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 > rev=0x01 hdr=0x00 > > The PCI ID's listed aren't AHCI so are using legacy ata not ahci, the two > devices listed are:- > { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, > { ATA_I82801GB_S1, 0, INTEL_ICH7, 0, ATA_SA300, "ICH7" }, > > Boot details:- > atapci0: port.. > ata0: at channel 0 on atapci0 > atapci1: port... > ata2: at channel 0 on atapci1 > ata3: at channel 1 on atapci1 > > Then your disks:- > ada3 at ata2 bus 0 scbus1 target 1 lun 0 > ada3: ATA-8 SATA 3.x device > > So your disks are in theory connected to a sata 2 compatible controller > which is being correctly identified. > > You might want to try a verbose boot to see if that gives any information. > > Also check your bios to see if it has an AHCI mode for the controller > and try that as its currently running in legacy. Steve, His controller model is ATA_I82801GB_S1, but does not support AHCI per Intel spec. The "Desktop" revision of ICH7 (not ICH7R) does not support AHCI, but supports SATA300. The "Mobile" revision of ICH7 does not support AHCI and also is limited to SATA150. He has the "Desktop" revision. Your above dmesg/ada3 output shown does not indicate the negotiated PHY speed; it's showing the ATA IDENTIFY results, saying "this disk claims to support a SATA600 PHY". That's not the same thing. What's missing from your dmesg/ada3 output is the "transfer rate" and the supposed PHY speed. That is what's showing up wrong for Michael, and for another user too. However, it's a **cosmetic problem**, because the true throughput I/O rate, despite what dmesg (xpt(4)) says, is actually higher. Another user mailed me off-list and showed me this. I have a multitude of terminal windows open right now looking at source along with 3 or 4 instances of mutt running, answering a crapload of Email and trying to compose a mail to the list that outlines all of this. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 02:48:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B7D35A70 for ; Sun, 24 Feb 2013 02:48:02 +0000 (UTC) (envelope-from prvs=17673ed9fb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 32560F62 for ; Sun, 24 Feb 2013 02:48:01 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002371483.msg for ; Sun, 24 Feb 2013 02:48:01 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 24 Feb 2013 02:48:01 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17673ed9fb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <831FD16628DB483D9704498F80D1FC66@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> <91D7CC6D816644C68B49191192DD9A98@multiplay.co.uk> <20130224020759.GA46759@icarus.home.lan> Subject: Re: Old ICH7 SATA-2 question Date: Sun, 24 Feb 2013 02:48:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable , Michael BlackHeart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 02:48:02 -0000 ----- Original Message ----- From: "Jeremy Chadwick" To: "Steven Hartland" Cc: "Michael BlackHeart" ; "freebsd-stable" Sent: Sunday, February 24, 2013 2:07 AM Subject: Re: Old ICH7 SATA-2 question > On Sun, Feb 24, 2013 at 01:56:46AM -0000, Steven Hartland wrote: >> ----- Original Message ----- From: "Jeremy Chadwick" >> >> >On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: >> >>2013/2/24 Jeremy Chadwick : >> >> >> >>{snipping irrelevant stuff and fixing formatting} >> >> >> >>atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 >> >> vendor = 'Intel Corporation' >> >> device = 'N10/ICH7 Family SATA IDE Controller' >> >> >> >>{snip} >> > >> >I had written up a significantly longer reply to this Email, but once I >> >finished and went back reviewing the information provided, my memory >> >recalled having this exact conversation some time ago. After some >> >extensive digging, I found it -- circa late 2008: >> > >> >http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html >> > >> >The result of this conversation was that FreeBSD at the time -- this >> >would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: >> >ata_chipset.c (part of the classic ata(4) driver) was misidentifying the >> >different revisions of ICH7 and therefore limiting controller capacities >> >incorrectly. >> > >> >Possibly a regression has been introduced as a result of the ATA-via-CAM >> >migration (now the default), which uses a completely different set of >> >code. >> >> pciconf:- >> atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 >> rev=0x01 hdr=0x00 >> >> The PCI ID's listed aren't AHCI so are using legacy ata not ahci, the two >> devices listed are:- >> { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, >> { ATA_I82801GB_S1, 0, INTEL_ICH7, 0, ATA_SA300, "ICH7" }, >> >> Boot details:- >> atapci0: port.. >> ata0: at channel 0 on atapci0 >> atapci1: port... >> ata2: at channel 0 on atapci1 >> ata3: at channel 1 on atapci1 >> >> Then your disks:- >> ada3 at ata2 bus 0 scbus1 target 1 lun 0 >> ada3: ATA-8 SATA 3.x device >> >> So your disks are in theory connected to a sata 2 compatible controller >> which is being correctly identified. >> >> You might want to try a verbose boot to see if that gives any information. >> >> Also check your bios to see if it has an AHCI mode for the controller >> and try that as its currently running in legacy. > > Steve, > > His controller model is ATA_I82801GB_S1, but does not support AHCI per > Intel spec. The "Desktop" revision of ICH7 (not ICH7R) does not support > AHCI, but supports SATA300. The "Mobile" revision of ICH7 does not > support AHCI and also is limited to SATA150. He has the "Desktop" > revision. I've seen bios in the past which have the option to toggle between these hence worth checking. > Your above dmesg/ada3 output shown does not indicate the negotiated PHY > speed; it's showing the ATA IDENTIFY results, saying "this disk claims > to support a SATA600 PHY". That's not the same thing. Never said it did, just that it indicated it was connected to a sata 2 compatible controller, which rules out PCI ID issues indicated in the post you linked. > What's missing from your dmesg/ada3 output is the "transfer rate" and > the supposed PHY speed. That is what's showing up wrong for Michael, > and for another user too. > > However, it's a **cosmetic problem**, because the true throughput I/O > rate, despite what dmesg (xpt(4)) says, is actually higher. Another > user mailed me off-list and showed me this. Interesting, the sata revision of the device determines its reported speed. Looking the camcontrol output looks like the "default" case is being triggered where it doesn't think the sata revision is valid for some reason. A verbose boot may provide some insite into why this is. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 03:05:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B76DBD61 for ; Sun, 24 Feb 2013 03:05:37 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id 7BEF3107E for ; Sun, 24 Feb 2013 03:05:37 +0000 (UTC) Received: from [188.108.250.211] (helo=michael-think) by www81.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1U9RbM-0007EX-1N; Sun, 24 Feb 2013 03:46:08 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, "John Mehr" Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <20130125092723.GC79995@e-Gitt.NET> <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> Date: Sun, 24 Feb 2013 03:45:57 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97.5/16730/Sun Feb 24 02:11:46 2013) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 03:05:37 -0000 On Sun, 24 Feb 2013 01:36:36 +0100, John Mehr wrote: > Hello all, > I've believe I've made just about all of the progress optimizing svnup > as I can and I've just submitted it as a new port. With my ~ 350kb/s > DSL connection, it now takes just under 30 minutes to download a fresh > base/releng/8.3 tree using svnup (Subversion's svn takes approximately > 12 minutes). Incremental updates, such as tracking one of the stable > branches takes only 2-3 minutes. > For anyone that wants to preview the port before it gets added to the > ports tree (assuming I got the send-pr correct), the tarball is > located > at: > http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz > Please let me know if you find any issues. Maybe it's me, but: No Makefile. So I try manually: gurder> cc svnup.c /tmp//cconKEOv.o: In function `compare_md5': svnup.c:(.text+0x175e): undefined reference to `MD5Init' svnup.c:(.text+0x1774): undefined reference to `MD5Update' svnup.c:(.text+0x1785): undefined reference to `MD5End' /tmp//cconKEOv.o: In function `get_files': svnup.c:(.text+0x1f20): undefined reference to `MD5Init' svnup.c:(.text+0x1f4e): undefined reference to `MD5Update' svnup.c:(.text+0x1f5f): undefined reference to `MD5End' 9.0-STABLE FreeBSD 9.0-STABLE #17: Fri May 4 02:53:49 CEST 2012 Best regards, Michael From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 03:09:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2F60EAC for ; Sun, 24 Feb 2013 03:09:29 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 67A5210BC for ; Sun, 24 Feb 2013 03:09:29 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 42WG1l0020mlR8UA339VSr; Sun, 24 Feb 2013 03:09:29 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta11.emeryville.ca.mail.comcast.net with comcast id 439U1l0051t3BNj8X39Ug1; Sun, 24 Feb 2013 03:09:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 03CA573A31; Sat, 23 Feb 2013 19:09:28 -0800 (PST) Date: Sat, 23 Feb 2013 19:09:27 -0800 From: Jeremy Chadwick To: Michael BlackHeart Subject: Re: Old ICH7 SATA-2 question Message-ID: <20130224030927.GA46638@icarus.home.lan> References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130224001307.GA43436@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361675369; bh=++lPy7n4kozBHxGxIb2OrkwxUnYqcAgB2/vszmzVdrw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=EM4mLVMcens953zqnGwQ+Pji/tjfY6hJjKuTpQmtmoziGPuQnN3sYoMxCO9ubqXyy ZAfhPSaaZ/tQwqyIONiAU3fIgnjGRFWBIWAgezH+wss6Z2CTPO9VbpufYtz//xDBO/ jDWg2U6i3r89rTIrq2zSbwdN/keYxCoIGdxi/MWbYEkresjPSe/qLr3WSNQYJn6S0l 98TRBoOHH4N9juzhoH0CiyVGChUqAqmKKyS5UvSnb6gNJw25xhvx2BjjsOZA9VHIUR G0k5IDvML4vAfLX8cxAWbS0tZkyoaMBggzoie1IIhmT+wXdPIDhjQOHaQm+gvTH7KZ gFPe8rrONVlcw== Cc: mav@freebsd.org, freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 03:09:29 -0000 On Sat, Feb 23, 2013 at 04:13:07PM -0800, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: > > 2013/2/24 Jeremy Chadwick : > > > > {snipping irrelevant stuff and fixing formatting} > > > > atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'N10/ICH7 Family SATA IDE Controller' > > > > {snip} > > I had written up a significantly longer reply to this Email, but once I > finished and went back reviewing the information provided, my memory > recalled having this exact conversation some time ago. After some > extensive digging, I found it -- circa late 2008: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html > > The result of this conversation was that FreeBSD at the time -- this > would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: > ata_chipset.c (part of the classic ata(4) driver) was misidentifying the > different revisions of ICH7 and therefore limiting controller capacities > incorrectly. > > Possibly a regression has been introduced as a result of the ATA-via-CAM > migration (now the default), which uses a completely different set of > code. CC'ing mav@ because I need some help/clarification on this one. I received an off-list mail from another ICH7 user, particularly one who is using an SSD. Their controller is identical (same vendor/device ID), and all their devices also claim "SATA" as well as "150MBytes/sec". However, "diskinfo -t" on the individuals' SSD shows quite clearly rates of up to 200MBytes/second. So the issue appears to be cosmetic. The question is why. Let me clarify because some list members have already gotten confused about some of the information output by the kernel and utilities. I'm going to use my own system (different controller, etc.) to educate list members. The fact I'm using AHCI has no bearing on this educational section, let me make that clear! * The following output during boot reflects the results of the ATA IDENTIFY command, and indicates what the **disk itself** (or more specifically, the controller on the disk itself) claims it is capable of: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device This indicates the ada0 disk supports up to the SATA 2.x revision (i.e. SATA300). This DOES NOT indicate what the motherboard (or HBA) SATA controllers' PHY/port is operating at; it only indicates what the disk supports "up to". * The subsequent output during boot reflects the actual motherboard (or HBA) SATA controllers' PHY/port speed, including what has been negotiated: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) There's a 1:1 mapping between SATA revision and PHY speed, effectively, unless otherwise throttled down or forced in some manner. I'm reminded of the non-ATA_CAM function ata_satarev2str() where the revision map is like this: value 0 = "" (default speed value is used?? unsure) value 1 = "SATA150" (150MB/sec) value 2 = "SATA300" (300MB/sec) value 3 = "SATA600" (600MB/sec) value 0xff = "SATA" (default speed value is used) else = "???" (default speed value is used?? unsure) Now for the rest... I've taken a look at the code and it's very difficult for me to follow; I'm not entirely sure, but it does look like pieces of sys/dev/ata/chipsets are still used today. I need mav@ to verify that fact however, because if ata_intel_probe() isn't used any more, then that might explain what's going on here (possibly). The "negotiated speed" printing comes from sys/cam/ata/ata_xpt.c, in ata_announce_periph(). The code logic here is simple, while the complex bits (e.g. what sets CTS_SATA_VALID_REVISION) are elsewhere. First, the speed: 2022 /* Report connection speed */ 2023 speed = cpi.base_transfer_speed; 2024 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_ATA) { 2025 struct ccb_trans_settings_pata *pata = 2026 &cts.xport_specific.ata; 2027 2028 if (pata->valid & CTS_ATA_VALID_MODE) 2029 speed = ata_mode2speed(pata->mode); 2030 } 2031 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_SATA) { 2032 struct ccb_trans_settings_sata *sata = 2033 &cts.xport_specific.sata; 2034 2035 if (sata->valid & CTS_SATA_VALID_REVISION) 2036 speed = ata_revision2speed(sata->revision); 2037 } 2038 mb = speed / 1000; 2039 if (mb > 0) 2040 printf("%s%d: %d.%03dMB/s transfers", 2041 periph->periph_name, periph->unit_number, 2042 mb, speed % 1000); The if() statement that is being used in Michael's case is the one for XPORT_SATA, not XPORT_PATA; that will be proven further below. I then had two questions: 1. Where does base_transfer_speed get set? For SATA devices, it gets set in sys/dev/ata/ata-all.c (I think). The default value chosen is 150000: 1884 if (ch->flags & ATA_SATA) 1885 cpi->base_transfer_speed = 150000; 1886 else 1887 cpi->base_transfer_speed = 3300; 2. Where does CTS_SATA_VALID_REVISION get set, which can in effect override base_transfer_speed? The jury is still out on this one as you'll see. Now on to the "protocol revision" printing code, i.e. "SATA 2.x" -- remember we're talking about the negotiated speed/protocol, not what's returned from ATA IDENTIFY (e.g. "camcontrol identify") for the disk. 2060 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_SATA) { 2061 struct ccb_trans_settings_sata *sata = 2062 &cts.xport_specific.sata; 2063 2064 printf(" ("); 2065 if (sata->valid & CTS_SATA_VALID_REVISION) 2066 printf("SATA %d.x, ", sata->revision); 2067 else 2068 printf("SATA, "); 2069 if (sata->valid & CTS_SATA_VALID_MODE) 2070 printf("%s, ", ata_mode2string(sata->mode)); 2071 if ((sata->valid & CTS_ATA_VALID_ATAPI) && sata->atapi != 0) 2072 printf("ATAPI %dbytes, ", sata->atapi); 2073 if (sata->valid & CTS_SATA_VALID_BYTECOUNT) 2074 printf("PIO %dbytes", sata->bytecount); 2075 printf(")"); 2076 } 2077 printf("\n"); Here we can see that XPORT_SATA must be set, because Michael's kernel output clearly shows the above printf()s. But once again we're back to CTS_SATA_VALID_REVISION. Without CTS_SATA_VALID_REVISION being set, ata_xpt.c chooses to simply say "SATA". That's all -- just "SATA". And that is what Michael and others with this chip see. The question is, simply, why does this model of ICH7 result in the bit CTS_SATA_VALID_REVISION, in the "valid" member of the appropriate ccb_trans_settings_sata struct, not being set correctly. I dug further than this, but I ended up chasing my tail while trying to look at sys/dev/ata/ata-all.c in ataaction() to figure out what went on. I pretty much lost faith (well, not faith, just lost the driving force) when I tried to find ATA_GETREV -- it's generated during buildworld as an inline function and comes from a DEVMETHOD() macro expansion, I believe; look for ata_getrev instead. As I've said many times in the past: the rabbit hole is deep and it is very easy to get lost when you lack familiarity with this code. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 03:15:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 960D2101 for ; Sun, 24 Feb 2013 03:15:10 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by mx1.freebsd.org (Postfix) with ESMTP id 650A01104 for ; Sun, 24 Feb 2013 03:15:10 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 43Er1l0070mlR8UAA3FAPF; Sun, 24 Feb 2013 03:15:10 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta11.emeryville.ca.mail.comcast.net with comcast id 43F91l00C1t3BNj8X3F9Kf; Sun, 24 Feb 2013 03:15:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3767173A31; Sat, 23 Feb 2013 19:15:09 -0800 (PST) Date: Sat, 23 Feb 2013 19:15:09 -0800 From: Jeremy Chadwick To: Michael Ross Subject: Re: svn - but smaller? Message-ID: <20130224031509.GA47838@icarus.home.lan> References: <20130123144050.GG51786@e-Gitt.NET> <20130125092723.GC79995@e-Gitt.NET> <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361675710; bh=Bh53QGZ7drduTjmr6ZFLjAdqK4fEiApRHiB1MsG6+AE=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=TgtgvZBZUDMOCpvDPB+qj7Ffu4tbvhlG6BuIvX7uU/ZFjrCry/wb+SynxQFe7lyvc LQpAInw2oUNRByroeZGDeC1muxvn9A5i5KF8rKlt4OwyJ7c3186VmIB+btPjluV1JL UFIhicViYAHz+cK2zQx8zQuzcCouHse3g651/1tCAZVt7LwkJmybqTPi1AUYKDmVl7 YnNFyF3KxOIw6mJCargYRnpRYhG7o+vCcAcAjMQaVtNyhQDSAuieAG0nXf+NT1ObTK fUlkEMGAIZD512tg+sywqbekXaHNaJeTMRAIZ5AnRxOw08zefGxHX8dc4w4PgnYZJb K4mlitzWJFC5w== Cc: John Mehr , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 03:15:10 -0000 On Sun, Feb 24, 2013 at 03:45:57AM +0100, Michael Ross wrote: > On Sun, 24 Feb 2013 01:36:36 +0100, John Mehr wrote: > > > Hello all, > > I've believe I've made just about all of the progress optimizing svnup > > as I can and I've just submitted it as a new port. With my ~ 350kb/s > > DSL connection, it now takes just under 30 minutes to download a fresh > > base/releng/8.3 tree using svnup (Subversion's svn takes approximately > > 12 minutes). Incremental updates, such as tracking one of the stable > > branches takes only 2-3 minutes. > > For anyone that wants to preview the port before it gets added to the > > ports tree (assuming I got the send-pr correct), the tarball is > >located > > at: > > http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz > > Please let me know if you find any issues. > > > Maybe it's me, but: > > No Makefile. > So I try manually: > > gurder> cc svnup.c > /tmp//cconKEOv.o: In function `compare_md5': > svnup.c:(.text+0x175e): undefined reference to `MD5Init' > svnup.c:(.text+0x1774): undefined reference to `MD5Update' > svnup.c:(.text+0x1785): undefined reference to `MD5End' > /tmp//cconKEOv.o: In function `get_files': > svnup.c:(.text+0x1f20): undefined reference to `MD5Init' > svnup.c:(.text+0x1f4e): undefined reference to `MD5Update' > svnup.c:(.text+0x1f5f): undefined reference to `MD5End' > > > 9.0-STABLE FreeBSD 9.0-STABLE #17: Fri May 4 02:53:49 CEST 2012 Those are all defined in libmd (see MD5Init(3) man page). Thus: cc -o svnup svnup.c -lmd -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 03:56:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B285C5F2 for ; Sun, 24 Feb 2013 03:56:36 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id 5182411F5 for ; Sun, 24 Feb 2013 03:56:35 +0000 (UTC) Received: from [188.108.250.211] (helo=michael-think) by www81.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1U9ShW-00049Y-Dx; Sun, 24 Feb 2013 04:56:34 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Jeremy Chadwick" Subject: Re: svn - but smaller? References: <20130123144050.GG51786@e-Gitt.NET> <20130125092723.GC79995@e-Gitt.NET> <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> Date: Sun, 24 Feb 2013 04:56:23 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: <20130224031509.GA47838@icarus.home.lan> User-Agent: Opera Mail/12.14 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97.5/16731/Sun Feb 24 03:57:31 2013) Cc: John Mehr , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 03:56:36 -0000 On Sun, 24 Feb 2013 04:15:09 +0100, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 03:45:57AM +0100, Michael Ross wrote: >> On Sun, 24 Feb 2013 01:36:36 +0100, John Mehr wrote: >> >> > Hello all, >> > I've believe I've made just about all of the progress optimizing >> svnup >> > as I can and I've just submitted it as a new port. With my ~ >> 350kb/s >> > DSL connection, it now takes just under 30 minutes to download a >> fresh >> > base/releng/8.3 tree using svnup (Subversion's svn takes >> approximately >> > 12 minutes). Incremental updates, such as tracking one of the >> stable >> > branches takes only 2-3 minutes. >> > For anyone that wants to preview the port before it gets added to >> the >> > ports tree (assuming I got the send-pr correct), the tarball is >> >located >> > at: >> > http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz >> > Please let me know if you find any issues. >> >> >> Maybe it's me, but: >> >> No Makefile. >> So I try manually: >> >> gurder> cc svnup.c >> /tmp//cconKEOv.o: In function `compare_md5': >> svnup.c:(.text+0x175e): undefined reference to `MD5Init' >> svnup.c:(.text+0x1774): undefined reference to `MD5Update' >> svnup.c:(.text+0x1785): undefined reference to `MD5End' >> /tmp//cconKEOv.o: In function `get_files': >> svnup.c:(.text+0x1f20): undefined reference to `MD5Init' >> svnup.c:(.text+0x1f4e): undefined reference to `MD5Update' >> svnup.c:(.text+0x1f5f): undefined reference to `MD5End' >> >> >> 9.0-STABLE FreeBSD 9.0-STABLE #17: Fri May 4 02:53:49 CEST 2012 > > Those are all defined in libmd (see MD5Init(3) man page). Thus: > > cc -o svnup svnup.c -lmd > Thanks. gurder> ./svnup -h svn0.us-west.FreeBSD.org -b ports/head -l test Dumps core: http://gurder.ross.cx/misc/svnup.core From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 04:16:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D6D97D0 for ; Sun, 24 Feb 2013 04:16:40 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 0DCDA125E for ; Sun, 24 Feb 2013 04:16:40 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 44BR1l0011vN32cAB4GfcT; Sun, 24 Feb 2013 04:16:39 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id 44Ge1l00Y1t3BNj8i4GeRf; Sun, 24 Feb 2013 04:16:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8027573A31; Sat, 23 Feb 2013 20:16:38 -0800 (PST) Date: Sat, 23 Feb 2013 20:16:38 -0800 From: Jeremy Chadwick To: Michael Ross Subject: Re: svn - but smaller? Message-ID: <20130224041638.GA51493@icarus.home.lan> References: <20130125092723.GC79995@e-Gitt.NET> <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361679399; bh=HHd7rwif6jYzWXi78LJGVD9wMhVP8rMkvIUhpRJ2Ibg=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=T5FWf9Ll1SUWttimZ7pwoviArZ32hPd5H+Tj34PyZKjD2MCdllFJyeIcGK+IPtvIq MnDieaZlcyqmNgfWqMHdect16KeprIbIjahaZP025iWZW570aU9I543yz8N0mRKKdV zKRJy+/kwzTTBJgIJcudAOf/F3E5SGYeZ19oTGmnRr3GUHRYbwjYYE438ia03gEwpC Gor5H4N1vsVV4INWRBpgmOOZoyNZwLeBrWMbUQIq52/QjPRuRdXrB9YbRSf91Yxkd4 5ooOdZ5F1pZD+ROmRLQvUYmpwjjPsnCP+xTqi1zRalRnEzR1OH0oBpndACjt3zzTuW 6pU3xG6vIc15g== Cc: freebsd-stable@freebsd.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 04:16:40 -0000 On Sun, Feb 24, 2013 at 04:56:23AM +0100, Michael Ross wrote: > On Sun, 24 Feb 2013 04:15:09 +0100, Jeremy Chadwick wrote: > > >On Sun, Feb 24, 2013 at 03:45:57AM +0100, Michael Ross wrote: > >>On Sun, 24 Feb 2013 01:36:36 +0100, John Mehr wrote: > >> > >>> Hello all, > >>> I've believe I've made just about all of the progress > >>optimizing svnup > >>> as I can and I've just submitted it as a new port. With my > >>~ 350kb/s > >>> DSL connection, it now takes just under 30 minutes to > >>download a fresh > >>> base/releng/8.3 tree using svnup (Subversion's svn takes > >>approximately > >>> 12 minutes). Incremental updates, such as tracking one of > >>the stable > >>> branches takes only 2-3 minutes. > >>> For anyone that wants to preview the port before it gets > >>added to the > >>> ports tree (assuming I got the send-pr correct), the tarball is > >>>located > >>> at: > >>> http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz > >>> Please let me know if you find any issues. > >> > >> > >>Maybe it's me, but: > >> > >>No Makefile. > >>So I try manually: > >> > >>gurder> cc svnup.c > >>/tmp//cconKEOv.o: In function `compare_md5': > >>svnup.c:(.text+0x175e): undefined reference to `MD5Init' > >>svnup.c:(.text+0x1774): undefined reference to `MD5Update' > >>svnup.c:(.text+0x1785): undefined reference to `MD5End' > >>/tmp//cconKEOv.o: In function `get_files': > >>svnup.c:(.text+0x1f20): undefined reference to `MD5Init' > >>svnup.c:(.text+0x1f4e): undefined reference to `MD5Update' > >>svnup.c:(.text+0x1f5f): undefined reference to `MD5End' > >> > >> > >>9.0-STABLE FreeBSD 9.0-STABLE #17: Fri May 4 02:53:49 CEST 2012 > > > >Those are all defined in libmd (see MD5Init(3) man page). Thus: > > > >cc -o svnup svnup.c -lmd > > > > Thanks. > > gurder> ./svnup -h svn0.us-west.FreeBSD.org -b ports/head -l test > > Dumps core: http://gurder.ross.cx/misc/svnup.core Should be easy enough to debug: $ cc -g3 -ggdb -o svnup svnup.c -lmd $ gdb svnup (gdb) run -h svn0.us-west.FreeBSD.org -b ports/head -l test Then once it cores, provide the output from "bt" and/or "bt full". Might also be useful to compile with -Wall to see if there are any compile-time warnings. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 04:44:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF302B41 for ; Sun, 24 Feb 2013 04:44:23 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id 69DD714BD for ; Sun, 24 Feb 2013 04:44:23 +0000 (UTC) Received: from [188.108.250.211] (helo=michael-think) by www81.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1U9TRl-0007rq-EO; Sun, 24 Feb 2013 05:44:22 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Jeremy Chadwick" Subject: Re: svn - but smaller? References: <20130125092723.GC79995@e-Gitt.NET> <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> Date: Sun, 24 Feb 2013 05:44:10 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: <20130224041638.GA51493@icarus.home.lan> User-Agent: Opera Mail/12.14 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97.5/16731/Sun Feb 24 03:57:31 2013) Cc: John Mehr , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 04:44:23 -0000 On Sun, 24 Feb 2013 05:16:38 +0100, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 04:56:23AM +0100, Michael Ross wrote: >> On Sun, 24 Feb 2013 04:15:09 +0100, Jeremy Chadwick >> wrote: >> >> >On Sun, Feb 24, 2013 at 03:45:57AM +0100, Michael Ross wrote: >> >>On Sun, 24 Feb 2013 01:36:36 +0100, John Mehr wrote: >> >> >> >>> Hello all, >> >>> I've believe I've made just about all of the progress >> >>optimizing svnup >> >>> as I can and I've just submitted it as a new port. With my >> >>~ 350kb/s >> >>> DSL connection, it now takes just under 30 minutes to >> >>download a fresh >> >>> base/releng/8.3 tree using svnup (Subversion's svn takes >> >>approximately >> >>> 12 minutes). Incremental updates, such as tracking one of >> >>the stable >> >>> branches takes only 2-3 minutes. >> >>> For anyone that wants to preview the port before it gets >> >>added to the >> >>> ports tree (assuming I got the send-pr correct), the tarball is >> >>>located >> >>> at: >> >>> http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz >> >>> Please let me know if you find any issues. >> >> >> >> >> >>Maybe it's me, but: >> >> >> >>No Makefile. >> >>So I try manually: >> >> >> >>gurder> cc svnup.c >> >>/tmp//cconKEOv.o: In function `compare_md5': >> >>svnup.c:(.text+0x175e): undefined reference to `MD5Init' >> >>svnup.c:(.text+0x1774): undefined reference to `MD5Update' >> >>svnup.c:(.text+0x1785): undefined reference to `MD5End' >> >>/tmp//cconKEOv.o: In function `get_files': >> >>svnup.c:(.text+0x1f20): undefined reference to `MD5Init' >> >>svnup.c:(.text+0x1f4e): undefined reference to `MD5Update' >> >>svnup.c:(.text+0x1f5f): undefined reference to `MD5End' >> >> >> >> >> >>9.0-STABLE FreeBSD 9.0-STABLE #17: Fri May 4 02:53:49 CEST 2012 >> > >> >Those are all defined in libmd (see MD5Init(3) man page). Thus: >> > >> >cc -o svnup svnup.c -lmd >> > >> >> Thanks. >> >> gurder> ./svnup -h svn0.us-west.FreeBSD.org -b ports/head -l test >> >> Dumps core: http://gurder.ross.cx/misc/svnup.core > > Should be easy enough to debug: > > $ cc -g3 -ggdb -o svnup svnup.c -lmd > $ gdb svnup > (gdb) run -h svn0.us-west.FreeBSD.org -b ports/head -l test > > Then once it cores, provide the output from "bt" and/or "bt full". > > Might also be useful to compile with -Wall to see if there are any > compile-time warnings. > gurder> cc -Wall -g3 -ggdb -o svnup svnup.c -lmd svnup.c: In function 'main': svnup.c:1002: warning: zero-length printf format string svnup.c:1020: warning: zero-length printf format string svnup.c:1027: warning: zero-length printf format string svnup.c:1065: warning: zero-length printf format string (gdb) run -h svn0.us-west.FreeBSD.org -b ports/head -l test Starting program: /usr/ports/sysutils/svnup-0.5/svnup -h svn0.us-west.FreeBSD.org -b ports/head -l test ####### Fetching revision: 312860 ? test/archivers Program received signal SIGSEGV, Segmentation fault. 0x0000000800b22950 in strchr () from /lib/libc.so.7 Backtrace: http://gurder.ross.cx/misc/backtrace.txt From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 05:48:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1D32F05; Sun, 24 Feb 2013 05:48:30 +0000 (UTC) (envelope-from prvs=17673ed9fb=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0D94F15EF; Sun, 24 Feb 2013 05:48:29 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002374766.msg; Sun, 24 Feb 2013 05:48:25 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 24 Feb 2013 05:48:25 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17673ed9fb=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <0568D24FDB4B4057B59AC1433E75B1BE@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" , "Michael BlackHeart" References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> <20130224030927.GA46638@icarus.home.lan> Subject: Re: Old ICH7 SATA-2 question Date: Sun, 24 Feb 2013 05:48:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: mav@freebsd.org, freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 05:48:30 -0000 ----- Original Message ----- From: "Jeremy Chadwick" > On Sat, Feb 23, 2013 at 04:13:07PM -0800, Jeremy Chadwick wrote: >> On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: >> > 2013/2/24 Jeremy Chadwick : >> > >> > {snipping irrelevant stuff and fixing formatting} >> > >> > atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = 'N10/ICH7 Family SATA IDE Controller' >> > >> > {snip} >> >> I had written up a significantly longer reply to this Email, but once I >> finished and went back reviewing the information provided, my memory >> recalled having this exact conversation some time ago. After some >> extensive digging, I found it -- circa late 2008: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html >> >> The result of this conversation was that FreeBSD at the time -- this >> would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: >> ata_chipset.c (part of the classic ata(4) driver) was misidentifying the >> different revisions of ICH7 and therefore limiting controller capacities >> incorrectly. >> >> Possibly a regression has been introduced as a result of the ATA-via-CAM >> migration (now the default), which uses a completely different set of >> code. > > CC'ing mav@ because I need some help/clarification on this one. > > I received an off-list mail from another ICH7 user, particularly one who > is using an SSD. Their controller is identical (same vendor/device ID), > and all their devices also claim "SATA" as well as "150MBytes/sec". > > However, "diskinfo -t" on the individuals' SSD shows quite clearly rates > of up to 200MBytes/second. > > So the issue appears to be cosmetic. The question is why. > > Let me clarify because some list members have already gotten confused > about some of the information output by the kernel and utilities. I'm > going to use my own system (different controller, etc.) to educate list > members. The fact I'm using AHCI has no bearing on this educational > section, let me make that clear! > > * The following output during boot reflects the results of the ATA > IDENTIFY command, and indicates what the **disk itself** (or more > specifically, the controller on the disk itself) claims it is capable > of: > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device The "at ahcichX" indicates your using AHCI as you stated, if however you see "at ataX" then your using the legacy ata driver still. > This indicates the ada0 disk supports up to the SATA 2.x revision (i.e. > SATA300). This DOES NOT indicate what the motherboard (or HBA) SATA > controllers' PHY/port is operating at; it only indicates what the disk > supports "up to". > > * The subsequent output during boot reflects the actual motherboard (or > HBA) SATA controllers' PHY/port speed, including what has been > negotiated: > > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > There's a 1:1 mapping between SATA revision and PHY speed, effectively, > unless otherwise throttled down or forced in some manner. I'm reminded > of the non-ATA_CAM function ata_satarev2str() where the revision map is > like this: > > value 0 = "" (default speed value is used?? unsure) > value 1 = "SATA150" (150MB/sec) > value 2 = "SATA300" (300MB/sec) > value 3 = "SATA600" (600MB/sec) > value 0xff = "SATA" (default speed value is used) > else = "???" (default speed value is used?? unsure) > > Now for the rest... > > I've taken a look at the code and it's very difficult for me to follow; > I'm not entirely sure, but it does look like pieces of > sys/dev/ata/chipsets are still used today. I need mav@ to verify that > fact however, because if ata_intel_probe() isn't used any more, then > that might explain what's going on here (possibly). When not using ahci this code is still used like in this case seen in boot via:- ada2 at ata2 bus 0 scbus1 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) "at ata2" shows its using the old ata driver, which is expected if the controller doesn't have an ahci mode. > The "negotiated speed" printing comes from sys/cam/ata/ata_xpt.c, in > ata_announce_periph(). The code logic here is simple, while the complex > bits (e.g. what sets CTS_SATA_VALID_REVISION) are elsewhere. Yes as I said looks like its using the default case for speed, so for some reason the sata revision isn't being flagged as valid. Having a quick look I'd suspect ata_sata_getrev or ata_intel_sata_getrev is going to be where this info is coming from Some blocks that stood out as something to check are:- This on interacts with how reg = ATA_SSTATUS could be retrieve:- if ((ctlr->chip->cfg1 & INTEL_ICH7)) { ch->hw.pm_read = ata_intel_sata_ahci_read; ch->hw.pm_write = ata_intel_sata_ahci_write; } else { ch->hw.pm_read = ata_intel_sata_sidpr_read; ch->hw.pm_write = ata_intel_sata_sidpr_write; } This one sets up a custom handler for getrev, possibly needs another special case for INTEL_ICH7? if (ctlr->r_res2 != NULL || (ctlr->chip->cfg1 & INTEL_ICH5)) ctlr->getrev = ata_intel_sata_getrev; As you've said its quite deep in the HW specific code so mav@ is likely you're man. However if someone has the specs for the HW and access to HW to test on it shouldn't be too hard to track down tbh. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 06:31:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C99A7F0 for ; Sun, 24 Feb 2013 06:31:13 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 18D9C16C9 for ; Sun, 24 Feb 2013 06:31:13 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 44ec1l0051smiN4A16XCdQ; Sun, 24 Feb 2013 06:31:12 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id 46XB1l0011t3BNj8g6XBDF; Sun, 24 Feb 2013 06:31:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F071173A31; Sat, 23 Feb 2013 22:31:10 -0800 (PST) Date: Sat, 23 Feb 2013 22:31:10 -0800 From: Jeremy Chadwick To: Michael Ross Subject: Re: svn - but smaller? Message-ID: <20130224063110.GA53348@icarus.home.lan> References: <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361687472; bh=dvi27qLxjGrKb/1U8RvbaYefWgqxtSyS0d6rwQ0z4ow=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=V9pngpZ5bDlvt+jsJ/NkvkCdRwj2ebvfZPsNVSCcF60U+vaRcQGLUSrmshST0SUpv s7mM8RuuYwAvOqEd+wzrk+3RcWICHo8UFJQrliyvNuZr5HdVwIxW59E1/vq81FYfEg pavR5aGLSX1FjwuY4Gee9vPeLEC/hGWO8jHGTPFwxedB23AR6s0uLfGeTvowECtu3p /H9HxVJf2SzCULu8NW51NkvqmMxAv/4i0urhR8IEpVQeQ5W6T5LK5PWA3+ThP/7GKR 98h9qnouDidRIglGcYc/Boq25+eNOsGB45ZYLY4WjcZWrXIeysI9kcfryx4oNVeCXe ZHH9Hi1o2R8cw== Cc: freebsd-stable@freebsd.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 06:31:13 -0000 On Sun, Feb 24, 2013 at 05:44:10AM +0100, Michael Ross wrote: > On Sun, 24 Feb 2013 05:16:38 +0100, Jeremy Chadwick wrote: > > >On Sun, Feb 24, 2013 at 04:56:23AM +0100, Michael Ross wrote: > >>On Sun, 24 Feb 2013 04:15:09 +0100, Jeremy Chadwick > >> wrote: > >> > >>>On Sun, Feb 24, 2013 at 03:45:57AM +0100, Michael Ross wrote: > >>>>On Sun, 24 Feb 2013 01:36:36 +0100, John Mehr wrote: > >>>> > >>>>> Hello all, > >>>>> I've believe I've made just about all of the progress > >>>>optimizing svnup > >>>>> as I can and I've just submitted it as a new port. With my > >>>>~ 350kb/s > >>>>> DSL connection, it now takes just under 30 minutes to > >>>>download a fresh > >>>>> base/releng/8.3 tree using svnup (Subversion's svn takes > >>>>approximately > >>>>> 12 minutes). Incremental updates, such as tracking one of > >>>>the stable > >>>>> branches takes only 2-3 minutes. > >>>>> For anyone that wants to preview the port before it gets > >>>>added to the > >>>>> ports tree (assuming I got the send-pr correct), the tarball is > >>>>>located > >>>>> at: > >>>>> http://jcm.dsl.visi.com/freebsd/svnup/svnup-0.5.tar.xz > >>>>> Please let me know if you find any issues. > >>>> > >>>> > >>>>Maybe it's me, but: > >>>> > >>>>No Makefile. > >>>>So I try manually: > >>>> > >>>>gurder> cc svnup.c > >>>>/tmp//cconKEOv.o: In function `compare_md5': > >>>>svnup.c:(.text+0x175e): undefined reference to `MD5Init' > >>>>svnup.c:(.text+0x1774): undefined reference to `MD5Update' > >>>>svnup.c:(.text+0x1785): undefined reference to `MD5End' > >>>>/tmp//cconKEOv.o: In function `get_files': > >>>>svnup.c:(.text+0x1f20): undefined reference to `MD5Init' > >>>>svnup.c:(.text+0x1f4e): undefined reference to `MD5Update' > >>>>svnup.c:(.text+0x1f5f): undefined reference to `MD5End' > >>>> > >>>> > >>>>9.0-STABLE FreeBSD 9.0-STABLE #17: Fri May 4 02:53:49 CEST 2012 > >>> > >>>Those are all defined in libmd (see MD5Init(3) man page). Thus: > >>> > >>>cc -o svnup svnup.c -lmd > >>> > >> > >>Thanks. > >> > >>gurder> ./svnup -h svn0.us-west.FreeBSD.org -b ports/head -l test > >> > >>Dumps core: http://gurder.ross.cx/misc/svnup.core > > > >Should be easy enough to debug: > > > >$ cc -g3 -ggdb -o svnup svnup.c -lmd > >$ gdb svnup > >(gdb) run -h svn0.us-west.FreeBSD.org -b ports/head -l test > > > >Then once it cores, provide the output from "bt" and/or "bt full". > > > >Might also be useful to compile with -Wall to see if there are any > >compile-time warnings. > > > > gurder> cc -Wall -g3 -ggdb -o svnup svnup.c -lmd > svnup.c: In function 'main': > svnup.c:1002: warning: zero-length printf format string > svnup.c:1020: warning: zero-length printf format string > svnup.c:1027: warning: zero-length printf format string > svnup.c:1065: warning: zero-length printf format string > > > (gdb) run -h svn0.us-west.FreeBSD.org -b ports/head -l test > Starting program: /usr/ports/sysutils/svnup-0.5/svnup -h > svn0.us-west.FreeBSD.org -b ports/head -l test > ####### Fetching revision: 312860 > ? test/archivers > Program received signal SIGSEGV, Segmentation fault. > 0x0000000800b22950 in strchr () from /lib/libc.so.7 > > Backtrace: http://gurder.ross.cx/misc/backtrace.txt I downloaded it and looked at the source. svnup.c:1002: warning: zero-length printf format string svnup.c:1020: warning: zero-length printf format string svnup.c:1027: warning: zero-length printf format string svnup.c:1065: warning: zero-length printf format string 1002 sprintf(command, ""); 1020 sprintf(command, ""); 1027 sprintf(command, ""); 1065 sprintf(command, ""); I'm not sure what the intention is here. If it's to terminate the buffer, then all of these should be: command[0] = '\0'; Or if the entire command[] buffer needs to be zeroed, use memset(3). Doing this does not fix the segfault. The segfault experienced is caused by the following problem: Program received signal SIGSEGV, Segmentation fault. 0x00000000a0b2eb10 in strchr () from /lib/libc.so.7 (gdb) bt #0 0x00000000a0b2eb10 in strchr () from /lib/libc.so.7 #1 0x00000000004021e8 in build_source_directory_tree (connection=0x7fffffff4820, command=0x7ffffffc3650 "", file=0xa1135000, file_count=0x7fffffff48f8, max_file=0x7fffffff48fc, path_target=0xa1009058 "test", revision=0) at svnup.c:412 #2 0x0000000000000000 in ?? () (gdb) f 1 #1 0x00000000004021e8 in build_source_directory_tree (connection=0x7fffffff4820, command=0x7ffffffc3650 "", file=0xa1135000, file_count=0x7fffffff48f8, max_file=0x7fffffff48fc, path_target=0xa1009058 "test", revision=0) at svnup.c:412 412 end = strchr(directory, '\n'); (gdb) p directory $1 = 0x0 It's a wee bit hard to do strchr() on something that points to NULL. At line 412 I inserted this, which is almost certainly not sufficient/correct: if (directory == NULL) { continue; } This allows the program to get a bit further than before (same goes if I use break instead of continue), but not before segfaulting again. And segfaults after this point contain a completely smashed stack: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000000000000 in ?? () John will need to look into these. They all reek of string parsing anomalies and so on. I would need to sit down and read/understand the code in full to know how to fix this one. Also, John, please consider using malloc(3) instead of heap-allocated buffers like file_buffer[6][] (196608 bytes) and command[] (32769 bytes). I'm referring to this: 47 #define COMMAND_BUFFER 32768 386 char new_path_target[BUFFER_UNIT], file_buffer[6][COMMAND_BUFFER], *path_source; 836 char *start, *value, *addr, *branch, *path_target, temp_file[BUFFER_UNIT], command[COMMAND_BUFFER + 1]; I should also point out that watching this thing in top(1) shows RES/RSS increasing until the segfault (for me dies out around 4.5MBytes). I don't know if that's by design or not, but I don't see why this thing would need so much memory given what it's doing. You'd know better than I though. You may want to consider running this under valgrind. It's remarkable what you can find with that during debugging. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 08:22:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69AF0172; Sun, 24 Feb 2013 08:22:20 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6F018BF; Sun, 24 Feb 2013 08:22:20 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id A50E8221010; Sun, 24 Feb 2013 04:22:12 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 14503-06; Sun, 24 Feb 2013 08:22:12 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 9822422100E; Sun, 24 Feb 2013 04:22:11 -0400 (AST) From: Marc Fournier Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: 9-STABLE: bce pulse(): Warning: bootcode thinks driver is absent Date: Sun, 24 Feb 2013 00:22:10 -0800 Message-Id: To: "freebsd-stable@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 08:22:20 -0000 I just started to try and get VirtualBox up and running on this server = .. same configuration as another server I already have a few of them = running, but after a period of time with the install, I get the above = error pop up on my remote console, and pinging to the server itself just = dies =85 I'm up to date for src / 9-STABLE as of today =85 have never seen this = one before, nor can I seem to find anything useful through google except = for points to the code itself =85 When it dies, it isn't just the network that is dead, but the whole = machine appears to be un-responsive =85 When I rebuilt the kernel, I did also rebuild VirtualBox/kmod, since = I've experienced odd things with it in the past =85=20 Anyone have any ideas on what is causing this? Something with = VirtualBox triggering =85 something? Thx From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 08:26:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 365803FF; Sun, 24 Feb 2013 08:26:48 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id C885418FE; Sun, 24 Feb 2013 08:26:47 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id EEA91191CEAE; Sun, 24 Feb 2013 04:26:46 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 16009-01; Sun, 24 Feb 2013 08:26:46 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id DBBB1191CEAD; Sun, 24 Feb 2013 04:26:45 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE: bce pulse(): Warning: bootcode thinks driver is absent From: Marc Fournier In-Reply-To: Date: Sun, 24 Feb 2013 00:26:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "freebsd-stable@freebsd.org" X-Mailer: Apple Mail (2.1499) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 08:26:48 -0000 Further to this =85 I just did a 'ctl-alt-del' through my remote = console, which appears to have 'unstuck' whatever it was, in that I got = a bunch of Login: prompts scroll up the screen (hit return a few times = after it got stuck), after which it seems to do a full shutdown and = reboot, as if nothing was wrong =85 I had a ping process running against that machine, which halted =85 but = when I hit ctl-alt-del, a whack of responses came back with really high = times: =3D=3D=3D 64 bytes from 200.46.151.146: icmp_seq=3D3104 ttl=3D64 time=3D215390.333 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3105 ttl=3D64 time=3D214389.342 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3286 ttl=3D64 time=3D33295.200 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3287 ttl=3D64 time=3D32294.228 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3288 ttl=3D64 time=3D31296.220 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3289 ttl=3D64 time=3D30296.262 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3315 ttl=3D64 time=3D4299.235 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3316 ttl=3D64 time=3D3299.278 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3317 ttl=3D64 time=3D2298.324 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3318 ttl=3D64 time=3D1299.448 = ms 64 bytes from 200.46.151.146: icmp_seq=3D3319 ttl=3D64 time=3D298.485 ms 64 bytes from 200.46.151.146: icmp_seq=3D3320 ttl=3D64 time=3D0.168 ms 64 bytes from 200.46.151.146: icmp_seq=3D3321 ttl=3D64 time=3D0.158 ms 64 bytes from 200.46.151.146: icmp_seq=3D3322 ttl=3D64 time=3D0.167 ms 64 bytes from 200.46.151.146: icmp_seq=3D3323 ttl=3D64 time=3D0.157 ms 64 bytes from 200.46.151.146: icmp_seq=3D3330 ttl=3D64 time=3D0.137 ms 64 bytes from 200.46.151.146: icmp_seq=3D3331 ttl=3D64 time=3D0.159 ms 64 bytes from 200.46.151.146: icmp_seq=3D3332 ttl=3D64 time=3D0.154 ms 64 bytes from 200.46.151.146: icmp_seq=3D3333 ttl=3D64 time=3D0.204 ms On 2013-02-24, at 12:22 AM, Marc Fournier wrote: >=20 > I just started to try and get VirtualBox up and running on this server = .. same configuration as another server I already have a few of them = running, but after a period of time with the install, I get the above = error pop up on my remote console, and pinging to the server itself just = dies =85 >=20 > I'm up to date for src / 9-STABLE as of today =85 have never seen this = one before, nor can I seem to find anything useful through google except = for points to the code itself =85 >=20 > When it dies, it isn't just the network that is dead, but the whole = machine appears to be un-responsive =85 >=20 > When I rebuilt the kernel, I did also rebuild VirtualBox/kmod, since = I've experienced odd things with it in the past =85=20 >=20 > Anyone have any ideas on what is causing this? Something with = VirtualBox triggering =85 something? >=20 > Thx >=20 >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 08:56:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A6C76BC; Sun, 24 Feb 2013 08:56:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 709AF19A2; Sun, 24 Feb 2013 08:56:14 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id s4so1543410lbc.35 for ; Sun, 24 Feb 2013 00:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=377dVfPAflcw1D61SleO4Egj3lVEqlBTrFgjGN7/xBA=; b=P2vsS/IQRr1oAx8envmIEEooKYqzT6lkHUB0nMtStOflaLgLrEt5Xyl1JNlXlUC5tW w0umLAyByE+3hLWEYbsBMeSiY/uKc29nF+6kW2V8IfNPGF1pogbVCaUubUXFv81A19GM Z6uB89JuTxfu8Zm2QGdOaeA287RU0zCNmwNPwMBMuxhf5O+5G6GJ21p4P52baW62Gcox znuRiEEoiK4nXETs3hoet4GySNzglqcqsiaLPgN6xGZbqDnAcw71gGNvI/SSdFxp4MSZ B9+6XEAOB55oI3GnrccJhNwBPOucpXzGh8YGd4H4AZh95LlxY2Baavy/ExNleSU5LeBn FDaw== X-Received: by 10.112.50.169 with SMTP id d9mr2987995lbo.57.1361696172830; Sun, 24 Feb 2013 00:56:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id fz16sm4491730lab.5.2013.02.24.00.56.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 00:56:11 -0800 (PST) Sender: Alexander Motin Message-ID: <5129D5A8.7050702@FreeBSD.org> Date: Sun, 24 Feb 2013 10:56:08 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130125 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: Old ICH7 SATA-2 question References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> <20130224030927.GA46638@icarus.home.lan> In-Reply-To: <20130224030927.GA46638@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Steven Hartland , freebsd-stable , Michael BlackHeart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 08:56:15 -0000 On 24.02.2013 05:09, Jeremy Chadwick wrote: > On Sat, Feb 23, 2013 at 04:13:07PM -0800, Jeremy Chadwick wrote: >> On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: >>> 2013/2/24 Jeremy Chadwick : >>> >>> {snipping irrelevant stuff and fixing formatting} >>> >>> atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'N10/ICH7 Family SATA IDE Controller' >>> >>> {snip} >> >> I had written up a significantly longer reply to this Email, but once I >> finished and went back reviewing the information provided, my memory >> recalled having this exact conversation some time ago. After some >> extensive digging, I found it -- circa late 2008: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html >> >> The result of this conversation was that FreeBSD at the time -- this >> would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: >> ata_chipset.c (part of the classic ata(4) driver) was misidentifying the >> different revisions of ICH7 and therefore limiting controller capacities >> incorrectly. >> >> Possibly a regression has been introduced as a result of the ATA-via-CAM >> migration (now the default), which uses a completely different set of >> code. > > CC'ing mav@ because I need some help/clarification on this one. > > I received an off-list mail from another ICH7 user, particularly one who > is using an SSD. Their controller is identical (same vendor/device ID), > and all their devices also claim "SATA" as well as "150MBytes/sec". > > However, "diskinfo -t" on the individuals' SSD shows quite clearly rates > of up to 200MBytes/second. > > So the issue appears to be cosmetic. The question is why. > > Let me clarify because some list members have already gotten confused > about some of the information output by the kernel and utilities. I'm > going to use my own system (different controller, etc.) to educate list > members. The fact I'm using AHCI has no bearing on this educational > section, let me make that clear! > > * The following output during boot reflects the results of the ATA > IDENTIFY command, and indicates what the **disk itself** (or more > specifically, the controller on the disk itself) claims it is capable > of: > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > > This indicates the ada0 disk supports up to the SATA 2.x revision (i.e. > SATA300). This DOES NOT indicate what the motherboard (or HBA) SATA > controllers' PHY/port is operating at; it only indicates what the disk > supports "up to". > > * The subsequent output during boot reflects the actual motherboard (or > HBA) SATA controllers' PHY/port speed, including what has been > negotiated: > > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > There's a 1:1 mapping between SATA revision and PHY speed, effectively, > unless otherwise throttled down or forced in some manner. I'm reminded > of the non-ATA_CAM function ata_satarev2str() where the revision map is > like this: > > value 0 = "" (default speed value is used?? unsure) > value 1 = "SATA150" (150MB/sec) > value 2 = "SATA300" (300MB/sec) > value 3 = "SATA600" (600MB/sec) > value 0xff = "SATA" (default speed value is used) > else = "???" (default speed value is used?? unsure) > > Now for the rest... > > I've taken a look at the code and it's very difficult for me to follow; > I'm not entirely sure, but it does look like pieces of > sys/dev/ata/chipsets are still used today. I need mav@ to verify that > fact however, because if ata_intel_probe() isn't used any more, then > that might explain what's going on here (possibly). The code in sys/dev/ata/chipsets is still used for controllers not supported by more advanced ahci, siis and mvs drivers. Depending on specific chipset and BIOS revision and settings ICH7 may or may not support AHCI mode. > The "negotiated speed" printing comes from sys/cam/ata/ata_xpt.c, in > ata_announce_periph(). The code logic here is simple, while the complex > bits (e.g. what sets CTS_SATA_VALID_REVISION) are elsewhere. > > First, the speed: > > 2022 /* Report connection speed */ > 2023 speed = cpi.base_transfer_speed; > 2024 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_ATA) { > 2025 struct ccb_trans_settings_pata *pata = > 2026 &cts.xport_specific.ata; > 2027 > 2028 if (pata->valid & CTS_ATA_VALID_MODE) > 2029 speed = ata_mode2speed(pata->mode); > 2030 } > 2031 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_SATA) { > 2032 struct ccb_trans_settings_sata *sata = > 2033 &cts.xport_specific.sata; > 2034 > 2035 if (sata->valid & CTS_SATA_VALID_REVISION) > 2036 speed = ata_revision2speed(sata->revision); > 2037 } > 2038 mb = speed / 1000; > 2039 if (mb > 0) > 2040 printf("%s%d: %d.%03dMB/s transfers", > 2041 periph->periph_name, periph->unit_number, > 2042 mb, speed % 1000); > > The if() statement that is being used in Michael's case is the one for > XPORT_SATA, not XPORT_PATA; that will be proven further below. I then > had two questions: > > 1. Where does base_transfer_speed get set? > > For SATA devices, it gets set in sys/dev/ata/ata-all.c (I think). The > default value chosen is 150000: > > 1884 if (ch->flags & ATA_SATA) > 1885 cpi->base_transfer_speed = 150000; > 1886 else > 1887 cpi->base_transfer_speed = 3300; Right. It is the lowest possible speed, that is supported by this HBA. It is reported if we have no other information sources. > 2. Where does CTS_SATA_VALID_REVISION get set, which can in effect > override base_transfer_speed? > > The jury is still out on this one as you'll see. > > Now on to the "protocol revision" printing code, i.e. "SATA 2.x" -- > remember we're talking about the negotiated speed/protocol, not what's > returned from ATA IDENTIFY (e.g. "camcontrol identify") for the disk. > > 2060 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_SATA) { > 2061 struct ccb_trans_settings_sata *sata = > 2062 &cts.xport_specific.sata; > 2063 > 2064 printf(" ("); > 2065 if (sata->valid & CTS_SATA_VALID_REVISION) > 2066 printf("SATA %d.x, ", sata->revision); > 2067 else > 2068 printf("SATA, "); > 2069 if (sata->valid & CTS_SATA_VALID_MODE) > 2070 printf("%s, ", ata_mode2string(sata->mode)); > 2071 if ((sata->valid & CTS_ATA_VALID_ATAPI) && sata->atapi != 0) > 2072 printf("ATAPI %dbytes, ", sata->atapi); > 2073 if (sata->valid & CTS_SATA_VALID_BYTECOUNT) > 2074 printf("PIO %dbytes", sata->bytecount); > 2075 printf(")"); > 2076 } > 2077 printf("\n"); > > Here we can see that XPORT_SATA must be set, because Michael's kernel > output clearly shows the above printf()s. > > But once again we're back to CTS_SATA_VALID_REVISION. Without > CTS_SATA_VALID_REVISION being set, ata_xpt.c chooses to simply say > "SATA". That's all -- just "SATA". And that is what Michael and others > with this chip see. > > The question is, simply, why does this model of ICH7 result in the > bit CTS_SATA_VALID_REVISION, in the "valid" member of the appropriate > ccb_trans_settings_sata struct, not being set correctly. ICH7 SATA may be configured by BIOS in three different ways: 1. PCI BAR(5) is pointing to standard set of AHCI registers. In such case controller will be able to work as AHCI and real speeds will be reported by ahci(4) driver and printed as "SATA x.0". 2. PCI BAR(5) is pointing to vendor-specific set of SATA registers. In such case controller will work mostly as legacy ATA with ata(4) driver, but the code in chipset/ata-intel.c will be able use vendor-specific registers to report speed, that again will be printed as "SATA x.0". 3. PCI BAR(5) is not set at all (ctlr->r_res2 == NULL). In such case controller will work as pure legacy ATA with ata(4) driver, the code in chipset/ata-intel.c will still believe it is SATA, following the chip ID, but it will have no any idea about what is going on on SATA level. In such case just "SATA" will be printed and cpi->base_transfer_speed is used by CAM to report speed. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 12:05:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7138188 for ; Sun, 24 Feb 2013 12:05:00 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id 832C61E4B for ; Sun, 24 Feb 2013 12:05:00 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so2223070wib.8 for ; Sun, 24 Feb 2013 04:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=UWKeMUt+K+xB/RnZ90Zm/H2TY+cU1QJWHgIMwz0xLdc=; b=N6bt5uwNS11DA+l+aawmlOolU6IIIwamxAS4u9sR++VE2SPQx6Yw+03E8rxWhRGZqW gyM4CWzQSC4Vz28Zq6vtrm/5QeJb8aTP9w/H018n499LkPeKWUeJuWQijhgisdxzC9l1 QX38aWkviuceuI85ZOpZEJR30TepeL9oK9ZTi+g52p5qMLnNYIbAV15RhNnByP7Ur6nf OnQEJ6uJO1o/bBLOl8RfRPEXqGEhGdcShMi2K0p3kgdSNccXGgfnMIsBSHSm8yiQXOh9 ZwX/4R3cdxedae11VsEvVaXF7veYd0NKfIfi3udEYLIm3vTE3cz+qK5/zk4Q9DUGS59g x4Yg== X-Received: by 10.180.95.199 with SMTP id dm7mr6370498wib.20.1361707499277; Sun, 24 Feb 2013 04:04:59 -0800 (PST) Received: from melon.localnet (250.33.91.91.rev.sfr.net. [91.91.33.250]) by mx.google.com with ESMTPS id j4sm8542593wiz.10.2013.02.24.04.04.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 24 Feb 2013 04:04:58 -0800 (PST) From: David Demelier To: freebsd-stable@freebsd.org Subject: Re: Panic at shutdown Date: Sun, 24 Feb 2013 13:04:52 +0100 Message-ID: <1722921.irhDJY2y33@melon> User-Agent: KMail/4.9.5 (FreeBSD/9.1-RELEASE; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <51127767.1030007@gmail.com> <2872289.1yXr0e1VeO@melon.malikania.fr> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 12:05:01 -0000 Le mardi 12 f=E9vrier 2013 21:42:01 Ronald Klop a =E9crit : > On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier >=20 > wrote: > > Le mardi 12 f=E9vrier 2013 10:01:10 Andriy Gapon a =E9crit : > >> on 12/02/2013 09:57 David Demelier said the following: > >> > Yes I have added debugging option in my kernel. I have makeoptio= ns > >> > DEBUG=3D-g in my config. Do I need more ? > >>=20 > >> .symbols? > >=20 > > I don't understand what you are saying, I have > > /boot/kernel/kernel.symbols. > > Please tell me what I'm doing wrong. I've just read and done the st= eps > > written > > there : > >=20 > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug= - > > gdb.html > >=20 > > So I've run > >=20 > > # cd /usr/obj/usr/src/sys/Melon > > # kgdb kernel.debug /var/crash/vmcore.0 >=20 > Why not something like kgdb /boot/kernel/kernel.symbols > /var/crash/vmcore.0? > That looks like what the manual page of kgdb seems to suggest. >=20 > Regards, > Ronald. >=20 > > and that's the only trace I get using bt full : > >=20 > > 229 #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) > > (kgdb) bt full > > #0 doadump (textdump=3D) at pcpu.h:229 > > No locals. > > #1 0x0000000000000000 in ?? () > > No symbol table info available. > >=20 I have that, in fact I was using bt full instead of short bt : #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 #1 0x0000000000000004 in ?? () #2 0xffffffff805146b6 in kern_reboot (howto=3D260) at=20 /usr/src/sys/kern/kern_shutdown.c:448 #3 0xffffffff80514b79 in panic (fmt=3D0x1
)= at /usr/src/sys/kern/kern_shutdown.c:636 #4 0xffffffff8071e919 in trap_fatal (frame=3D0xc, eva=3DVariable "eva"= is not=20 available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #5 0xffffffff8071eca4 in trap_pfault (frame=3D0xffffff80d63db5d0, user= mode=3D0) at /usr/src/sys/amd64/amd64/trap.c:773 #6 0xffffffff8071f09b in trap (frame=3D0xffffff80d63db5d0) at=20 /usr/src/sys/amd64/amd64/trap.c:456 #7 0xffffffff8070993f in calltrap () at=20 /usr/src/sys/amd64/amd64/exception.S:228 #8 0xffffffff802ddbf5 in AcpiOsAcquireObject (Cache=3D0xfffffe00015de4= 00) at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 #9 0xffffffff802e27c1 in AcpiUtAllocateObjectDescDbg=20 (ModuleName=3D0xffffffff80795110 "dsutils",=20 LineNumber=3D703, ComponentId=3DVariable "ComponentId" is not avail= able. ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 #10 0xffffffff802e2972 in AcpiUtCreateInternalObjectDbg=20 (ModuleName=3D0xffffffff80795110 "dsutils",=20 LineNumber=3D703, ComponentId=3D64, Type=3D1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 #11 0xffffffff802b32ea in AcpiDsCreateOperand (WalkState=3D0xfffffe0003= 80fc00,=20 Arg=3D0xfffffe00017d39c0,=20 ArgIndex=3D0) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils= .c:703 #12 0xffffffff802b3686 in AcpiDsCreateOperands (WalkState=3D0xfffffe000= 380fc00,=20 FirstArg=3D0xfffffe00017d39c0) at=20 /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 #13 0xffffffff802b4323 in AcpiDsExecEndOp (WalkState=3D0xfffffe000380fc= 00) at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:449 #14 0xffffffff802d55e9 in AcpiPsParseLoop (WalkState=3D0xfffffe000380fc= 00) at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 #15 0xffffffff802d6a5b in AcpiPsParseAml (WalkState=3D0xfffffe000380fc0= 0) at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 #16 0xffffffff802d7ad7 in AcpiPsExecuteMethod (Info=3D0xfffffe00411b950= 0) at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 #17 0xffffffff802ce3af in AcpiNsEvaluate (Info=3D0xfffffe00411b9500) at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 #18 0xffffffff802d3567 in AcpiEvaluateObject (Handle=3D0xfffffe00017d6d= 40,=20 Pathname=3D0xffffffff807b2e9b "_TMP", ExternalParams=3D0x0,=20 ReturnBuffer=3D0xffffff80d63dba50) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfeval.c:289 #19 0xffffffff8031ca84 in acpi_GetInteger (handle=3D0xfffffe00017d6d40,= =20 path=3D0xffffffff807b2e9b "_TMP", number=3D0xffffff80d63dbab4) at=20= /usr/src/sys/dev/acpica/acpi.c:2204 #20 0xffffffff80331756 in acpi_tz_get_temperature (sc=3D0xfffffe0001a2f= a00) at /usr/src/sys/dev/acpica/acpi_thermal.c:462 #21 0xffffffff803329d6 in acpi_tz_monitor (Context=3D0xfffffe0001a2fa00= ) at /usr/src/sys/dev/acpica/acpi_thermal.c:497 #22 0xffffffff80332f92 in acpi_tz_thread (arg=3DVariable "arg" is not a= vailable. ) at /usr/src/sys/dev/acpica/acpi_thermal.c:864 #23 0xffffffff804e7a3d in fork_exit (callout=3D0xffffffff80332e50=20 , arg=3D0x0,=20 frame=3D0xffffff80d63dbc00) at /usr/src/sys/kern/kern_fork.c:992 #24 0xffffffff80709dfe in fork_trampoline () at=20 /usr/src/sys/amd64/amd64/exception.S:602 #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000001 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0xffffffff80b5b1c0 in affinity () #50 0x0000000000000000 in ?? () #51 0xfffffe0001a5e8b0 in ?? () #52 0xfffffe0001a5e470 in ?? () #53 0x0000000000000000 in ?? () #54 0xffffff80d63dba08 in ?? () #55 0xfffffe00016db8e0 in ?? () #56 0xffffffff8053ccf9 in sched_switch (td=3D0xffffffff80332e50, newtd=3D= 0x0,=20 flags=3DVariable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1921 #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000001 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0xffffff80d63dbdc0 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () #119 0x0000000000000000 in ?? () #120 0x0000000000000000 in ?? () #121 0x0000000000000000 in ?? () #122 0x0000000000000000 in ?? () #123 0x0000000000000000 in ?? () #124 0x0000000000000000 in ?? () #125 0x0000000000000000 in ?? () #126 0x0000000000000000 in ?? () #127 0x0000000000000000 in ?? () #128 0x0000000000000000 in ?? () #129 0x0000000000000000 in ?? () #130 0x0000000000000000 in ?? () #131 0x0000000000000000 in ?? () #132 0x0000000000000000 in ?? () #133 0x0000000000000000 in ?? () #134 0x0000000000000003 in ?? () #135 0x0000000000000000 in ?? () #136 0x0000000000000000 in ?? () #137 0x0000000000000000 in ?? () #138 0x0000000000000000 in ?? () #139 0x0000000000000000 in ?? () #140 0x0000000000000000 in ?? () #141 0x0000000000000000 in ?? () Cannot access memory at address 0xffffff80d63dc000 --=20 David Demelier From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 13:58:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C31CBA5 for ; Sun, 24 Feb 2013 13:58:10 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 12F1D1DC for ; Sun, 24 Feb 2013 13:58:08 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 09EE1450CE; Sun, 24 Feb 2013 13:58:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.7.4 isis.morrow.me.uk 09EE1450CE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1361714282; bh=fXtAC1L7pA1O2oXudsWgoncnFUdxDzK5da48r9wlD2U=; h=Date:From:To:Subject:References:In-Reply-To; b=oj6ahJ2IVylprw9qisfwagvKSGpeLFb1cD/uKRDra5SNxtBXiZD6KgSDOlgo9vaVH 7KCfNPMtIxT1VuBHkxOEJjdxqFFcF8FP/ETacau853qJ5aq6T9a+ZA1e3NiuU8N6YA RzTn0fVM25ntPO1VxmLlyEg76oCo0ju53s38MM2w= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id CB6CF915F; Sun, 24 Feb 2013 13:57:58 +0000 (GMT) Date: Sun, 24 Feb 2013 13:57:58 +0000 From: Ben Morrow To: jdc@koitsu.org, freebsd-stable@freebsd.org Subject: Re: Old ICH7 SATA-2 question Message-ID: <20130224135754.GA23889@anubis.morrow.me.uk> References: <20130223211932.GA41809@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130224001307.GA43436@icarus.home.lan> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 13:58:10 -0000 Quoth Jeremy Chadwick : > > If there are people out there using, for example, SSDs on an ICH7 in > non-AHCI mode, it would be good to know and get "pciconf -lvbc" output > (specifically the entry for their ATA/SATA controller). But as with all > publicly released operating systems, most Requests For Feedback are > ignored, things are then changed, and only afterwards do people crawl > out of their hobbit holes and speak up. :-) Since you asked: isab0@pci0:0:31:0: class=0x060100 card=0x50011458 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR (ICH7 Family) LPC Interface Bridge' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: Quick Resume, SATA RAID-5, 6 PCI-e x1 slots, SATA RAID-0/1/10, SATA AHCI atapci0@pci0:0:31:1: class=0x01018a card=0xb0011458 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xf000, size 16, enabled atapci1@pci0:0:31:2: class=0x01018f card=0xb0021458 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'N10/ICH7 Family SATA IDE Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xe800, size 8, enabled bar [14] = type I/O Port, range 32, base 0xe900, size 4, enabled bar [18] = type I/O Port, range 32, base 0xea00, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xeb00, size 4, enabled bar [20] = type I/O Port, range 32, base 0xec00, size 16, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 The motherboard manual claims it supports SATA 2 (3Gb/s). However, ada2 is an SSD, and camcontrol identify ada2 reports: pass2: ATA-8 SATA 3.x device pass2: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model KINGSTON SVP200S37A60G [...] so FreeBSD doesn't appear to know that. Ben From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 16:42:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF5BD2BF for ; Sun, 24 Feb 2013 16:42:46 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback3.g2host.com [208.42.184.243]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCDB90D for ; Sun, 24 Feb 2013 16:42:45 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback3.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 10871226 for freebsd-stable@freebsd.org; Sun, 24 Feb 2013 10:42:44 -0600 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Sun, 24 Feb 2013 10:42:44 -0600 Message-ID: In-Reply-To: <20130224063110.GA53348@icarus.home.lan> References: <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 16:42:46 -0000 On Sat, 23 Feb 2013 22:31:10 -0800 Jeremy Chadwick wrote: > > I downloaded it and looked at the source. > > svnup.c:1002: warning: zero-length printf format string > svnup.c:1020: warning: zero-length printf format string > svnup.c:1027: warning: zero-length printf format string > svnup.c:1065: warning: zero-length printf format string > > 1002 sprintf(command, ""); > 1020 sprintf(command, ""); > 1027 sprintf(command, ""); > 1065 sprintf(command, >""); > > I'm not sure what the intention is here. If it's to >terminate the > buffer, then all of these should be: > > command[0] = '\0'; Correct. Clang didn't complain when I went the sprintf route... :( > Also, John, please consider using malloc(3) instead of >heap-allocated > buffers like file_buffer[6][] (196608 bytes) and >command[] (32769 > bytes). I'm referring to this: > > 47 #define COMMAND_BUFFER 32768 > 386 char new_path_target[BUFFER_UNIT], >file_buffer[6][COMMAND_BUFFER], *path_source; > 836 char *start, *value, *addr, *branch, >*path_target, temp_file[BUFFER_UNIT], >command[COMMAND_BUFFER + 1]; These were leftovers from a malloc debug session that I forgot to undo. Processing the ports tree needs way more that six buffers... > I should also point out that watching this thing in >top(1) shows RES/RSS > increasing until the segfault (for me dies out around >4.5MBytes). I > don't know if that's by design or not, but I don't see >why this thing > would need so much memory given what it's doing. You'd >know better than > I though. The code is definitely going to be memory intensive. The initial, naive implementation I wrote sent get-file and get-dir requests one at a time and the time penalty was atrocious -- it took four hours to process base/releng/8.3. To get around this, since the subversion server can handle multiple requests at a time, I have to cram as many get-file and get-dir requests together as I can to minimize the number of interactions with the server. > You may want to consider running this under valgrind. > It's remarkable > what you can find with that during debugging. Will do. > > -- > | Jeremy Chadwick > jdc@koitsu.org | > | UNIX Systems Administrator > http://jdc.koitsu.org/ | > | Mountain View, CA, US > | > | Making life hard for others since 1977. > PGP 4BD6C0CB | > I've got a rough fix in place and the ports tree is chugging along now (I only tested my code against the base/releng and base/stable branches -- oops). I should be able to post revised code tonight. Thanks for taking a look at this. As a first-timer here, I definitely appreciate it! From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 19:59:03 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D180B45 for ; Sun, 24 Feb 2013 19:59:03 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5E64216D for ; Sun, 24 Feb 2013 19:59:03 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1OJwt2N007300; Sun, 24 Feb 2013 12:58:56 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1OJwqM6002212; Sun, 24 Feb 2013 12:58:52 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: svn - but smaller? From: Ian Lepore To: Jeremy Chadwick In-Reply-To: <20130224063110.GA53348@icarus.home.lan> References: <1359320641-6493504.60501067.fr0RL3aYw027137@rs149.luxsci.com> <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Feb 2013 10:19:57 -0700 Message-ID: <1361726397.16937.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 19:59:03 -0000 On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > Also, John, please consider using malloc(3) instead of heap-allocated > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > bytes). I'm referring to this: Why? I absolutely do not understand why people are always objecting to large stack-allocated arrays in userland code (sometimes with the definition of "large" being as small as 2k for some folks). -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 21:24:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C8906AB for ; Sun, 24 Feb 2013 21:24:38 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id C018C6BE for ; Sun, 24 Feb 2013 21:24:37 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 4M1e1l0031HpZEsA2MQd65; Sun, 24 Feb 2013 21:24:37 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 4MQc1l00S1t3BNj8aMQcCa; Sun, 24 Feb 2013 21:24:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 72A0473A1C; Sun, 24 Feb 2013 13:24:36 -0800 (PST) Date: Sun, 24 Feb 2013 13:24:36 -0800 From: Jeremy Chadwick To: Ian Lepore Subject: Re: svn - but smaller? Message-ID: <20130224212436.GA13670@icarus.home.lan> References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1361726397.16937.4.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361741077; bh=QteblBxRs7Hgkgex2XhmViQJrDsDuXwI6cppvX2T4Qs=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=BYhMuXPS+iJTGXKhVLyyWKwWIdo4cWUhvb2HyWPQPbFLQH/TpPSnfxHA7gArOFi31 kL7vrrWW+baIkI6GJiiHumbCpxyQOm7TncTZ3KRKcysnpzI/y7ZXTOcrrMTIKQjmW6 A/wAXXHlvSvx/cSpDsL3VeKy3mxoDRVT0aw2hQ/7B4fviWSUmAWBZMxEDVk4bneaWH iLzt2qeFOun/yeEr/cgMMpxNMaF5yLfuY/o/pjBgrYb0BrXadmVmbZjKadHtUUnpYn LgN54ek7UFML64BMTWnvlo1hk4zxt6zMrv6CUkJqNbcos+8cA6vvY0WEBKXJF0S0j4 1SAF5QV7Rvzgw== Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 21:24:38 -0000 On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > bytes). I'm referring to this: > > Why? I absolutely do not understand why people are always objecting to > large stack-allocated arrays in userland code (sometimes with the > definition of "large" being as small as 2k for some folks). This is incredibly off-topic, but I'll bite. I should not have said "heap-allocated", I was actually referring to statically-allocated. The issues as I see them: 1. Such buffers exist during the entire program's lifetime even if they aren't actively used/needed by the program. With malloc(3) and friends, you're allocating memory dynamically, and you can free(3) when done with it, rather than just having a gigantic portion of memory allocated sitting around potentially doing nothing. 2. If the length of the buffer exceeds the amount of stack space available at the time, the program will run but the behaviour is unknown (I know that on FreeBSD if it exceeds "stacksize" per resource limits, the program segfaults at runtime). With malloc and friends you can gracefully handle allocation failures. 3. Statically-allocated buffers can't grow; meaning what you've requested size-wise is all you get. Compare this to something that's dynamic -- think a linked list containing pointers to malloc'd memory, which can even be realloc(3)'d if needed. The definition of what's "too large" is up to the individual and the limits of the underlying application. For some people, sure, anything larger than 2048 might warrant use of malloc. I tend to use malloc for anything larger than 4096. That "magic number" comes from some piece of information I was told long ago about what size pages malloc internally uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it appears to be a lot more complex than that. If you want me to break down #1 for you with some real-world output and a very small C program, showing you the effects on RES/RSS and SIZE/VIRT of static vs. dynamic allocation, just ask. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 22:14:43 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AC1C1C4; Sun, 24 Feb 2013 22:14:43 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id E710C88E; Sun, 24 Feb 2013 22:14:42 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.6/8.14.6) with ESMTP id r1OMEWc6081849; Sun, 24 Feb 2013 16:14:33 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <512A90C8.6050007@missouri.edu> Date: Sun, 24 Feb 2013 16:14:32 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: svn - but smaller? References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> In-Reply-To: <20130224212436.GA13670@icarus.home.lan> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr , Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 22:14:43 -0000 On 02/24/2013 03:24 PM, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: >> On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: >>> >>> Also, John, please consider using malloc(3) instead of heap-allocated >>> buffers like file_buffer[6][] (196608 bytes) and command[] (32769 >>> bytes). I'm referring to this: >> >> Why? I absolutely do not understand why people are always objecting to >> large stack-allocated arrays in userland code (sometimes with the >> definition of "large" being as small as 2k for some folks). > > This is incredibly off-topic, but I'll bite. > > I should not have said "heap-allocated", I was actually referring to > statically-allocated. > > The issues as I see them: > > 2. If the length of the buffer exceeds the amount of stack space > available at the time, the program will run but the behaviour is unknown > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > the program segfaults at runtime). With malloc and friends you can > gracefully handle allocation failures. This actually happened to me. The program mkctm used to allocate space using alloca (which is the same as declaring it like char file_buffer[big_no] if big_no could be variable). But this is space on the stack as opposed to the heap, and if you type the command "limit" you will see that the stack size is typically much smaller than the heap size. And on 32 bit machines, the default value of stack size is rather small. Anyway, one day mkctm stopped working for me, and precisely for this reason. It took me a day to trace the fault, and I ended up rewriting the code to use malloc instead. (mkctm is a little known program, whose code is included in the FreeBSD base, to create updates for the CTM delivery method.) Probably on 64 bit machines it is not such a big issue. And on Linux, I think it makes no difference at all, because on Linux all data is stored on the heap. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 23:43:36 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8506B26 for ; Sun, 24 Feb 2013 23:43:36 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 94228E46 for ; Sun, 24 Feb 2013 23:43:36 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1ONhZTM009927; Sun, 24 Feb 2013 16:43:35 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1ONhXFB002889; Sun, 24 Feb 2013 16:43:33 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: svn - but smaller? From: Ian Lepore To: Jeremy Chadwick In-Reply-To: <20130224212436.GA13670@icarus.home.lan> References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Feb 2013 16:43:33 -0700 Message-ID: <1361749413.16937.16.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 23:43:36 -0000 On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > bytes). I'm referring to this: > > > > Why? I absolutely do not understand why people are always objecting to > > large stack-allocated arrays in userland code (sometimes with the > > definition of "large" being as small as 2k for some folks). > > This is incredibly off-topic, but I'll bite. > > I should not have said "heap-allocated", I was actually referring to > statically-allocated. > > The issues as I see them: > > 1. Such buffers exist during the entire program's lifetime even if they > aren't actively used/needed by the program. With malloc(3) and friends, > you're allocating memory dynamically, and you can free(3) when done with > it, rather than just having a gigantic portion of memory allocated > sitting around potentially doing nothing. > > 2. If the length of the buffer exceeds the amount of stack space > available at the time, the program will run but the behaviour is unknown > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > the program segfaults at runtime). With malloc and friends you can > gracefully handle allocation failures. > > 3. Statically-allocated buffers can't grow; meaning what you've > requested size-wise is all you get. Compare this to something that's > dynamic -- think a linked list containing pointers to malloc'd memory, > which can even be realloc(3)'d if needed. > > The definition of what's "too large" is up to the individual and the > limits of the underlying application. For some people, sure, anything > larger than 2048 might warrant use of malloc. I tend to use malloc for > anything larger than 4096. That "magic number" comes from some piece of > information I was told long ago about what size pages malloc internally > uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it > appears to be a lot more complex than that. > > If you want me to break down #1 for you with some real-world output and > a very small C program, showing you the effects on RES/RSS and SIZE/VIRT > of static vs. dynamic allocation, just ask. > Actually, after seeing that the userland limit for an unpriveleged user on freebsd is a mere 64k, I'd say the only valid reason to not allocate big things on the stack is because freebsd has completely broken defaults. I see no reason why there should even be a distinction between stack size and memory use limits in general. Pages are pages, it really doesn't matter what part of your virtual address space they live in. Almost everything I've ever done with freebsd runs as root on an embedded system, so I'm not used to thinking in terms of limits at all. -- Ian [P.S. Having mail troubles today, sorry if this gets duplicated.] From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 23:50:37 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7D06D07; Sun, 24 Feb 2013 23:50:37 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id BDDF7E91; Sun, 24 Feb 2013 23:50:37 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.6/8.14.6) with ESMTP id r1ONoYa3090743; Sun, 24 Feb 2013 17:50:35 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <512AA74A.4060708@missouri.edu> Date: Sun, 24 Feb 2013 17:50:34 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: svn - but smaller? References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> <1361749413.16937.16.camel@revolution.hippie.lan> In-Reply-To: <1361749413.16937.16.camel@revolution.hippie.lan> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 24 Feb 2013 23:50:38 -0000 On 02/24/2013 05:43 PM, Ian Lepore wrote: > On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: >> On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: >>> On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: >>>> >>>> Also, John, please consider using malloc(3) instead of heap-allocated >>>> buffers like file_buffer[6][] (196608 bytes) and command[] (32769 >>>> bytes). I'm referring to this: >>> >>> Why? I absolutely do not understand why people are always objecting to >>> large stack-allocated arrays in userland code (sometimes with the >>> definition of "large" being as small as 2k for some folks). >> >> This is incredibly off-topic, but I'll bite. >> >> I should not have said "heap-allocated", I was actually referring to >> statically-allocated. >> >> The issues as I see them: >> >> 1. Such buffers exist during the entire program's lifetime even if they >> aren't actively used/needed by the program. With malloc(3) and friends, >> you're allocating memory dynamically, and you can free(3) when done with >> it, rather than just having a gigantic portion of memory allocated >> sitting around potentially doing nothing. >> >> 2. If the length of the buffer exceeds the amount of stack space >> available at the time, the program will run but the behaviour is unknown >> (I know that on FreeBSD if it exceeds "stacksize" per resource limits, >> the program segfaults at runtime). With malloc and friends you can >> gracefully handle allocation failures. >> >> 3. Statically-allocated buffers can't grow; meaning what you've >> requested size-wise is all you get. Compare this to something that's >> dynamic -- think a linked list containing pointers to malloc'd memory, >> which can even be realloc(3)'d if needed. >> >> The definition of what's "too large" is up to the individual and the >> limits of the underlying application. For some people, sure, anything >> larger than 2048 might warrant use of malloc. I tend to use malloc for >> anything larger than 4096. That "magic number" comes from some piece of >> information I was told long ago about what size pages malloc internally >> uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it >> appears to be a lot more complex than that. >> >> If you want me to break down #1 for you with some real-world output and >> a very small C program, showing you the effects on RES/RSS and SIZE/VIRT >> of static vs. dynamic allocation, just ask. >> > > Actually, after seeing that the userland limit for an unpriveleged user > on freebsd is a mere 64k, I'd say the only valid reason to not allocate > big things on the stack is because freebsd has completely broken > defaults. I see no reason why there should even be a distinction > between stack size and memory use limits in general. Pages are pages, > it really doesn't matter what part of your virtual address space they > live in. I think that the stacksize and datasize cannot together add up to more than 4G, or maybe it is only 2G, at least on a 32 bit machine. This is because (I think) they compete for virtual memory address space. I guess this wasn't a problem in the old days, when 4G of RAM was unthinkable. Also, as I said in another thread, I think Linux doesn't make this distinction. So at least someone else out there agrees with you. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 00:04:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 387AC260 for ; Mon, 25 Feb 2013 00:04:56 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 0E149F1E for ; Mon, 25 Feb 2013 00:04:56 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 4Q191l0041Y3wxoA3Q4vwb; Mon, 25 Feb 2013 00:04:55 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id 4Q4u1l00A1t3BNj8bQ4uJK; Mon, 25 Feb 2013 00:04:55 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2E06E73A1C; Sun, 24 Feb 2013 16:04:54 -0800 (PST) Date: Sun, 24 Feb 2013 16:04:54 -0800 From: Jeremy Chadwick To: Ian Lepore Subject: Re: svn - but smaller? Message-ID: <20130225000454.GA17342@icarus.home.lan> References: <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> <1361749413.16937.16.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1361749413.16937.16.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361750695; bh=1KdzSfm3D2NNXyKE68w49PNB/J//c7q7sZMq/ECT8sI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=KEL5w0KdLAjgMkFEUOeZ+ofMQGN4qLvVpawCm73Yq4xJbHZex1WXxRcY2ILTjrCeh e4f5VHBpmMC7B3LWysrZdx5VwAc2Dye2st5rftZB94W1P12ukC5lpxuo0QFnto90eg l8DYrATcUx84arbBm6l7E/ntb2yHBf5cc1DPSP3ZvPl7WM0i0TNogR27Oo/e5vlP73 8OD0/PbhVLfkNBzuz0EQRuISo2jxFFcHgctCoclItzWO6kciRB2CRkyaWnGTX7gC8t q0F8JseZrrNkSzqAakHlDpKkruY3cBCq7rx2iwJFcogyVSV1OFgbTeZmJGS/B6loQ8 APrMhgEl9pYJg== Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 00:04:56 -0000 On Sun, Feb 24, 2013 at 04:43:33PM -0700, Ian Lepore wrote: > On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > > bytes). I'm referring to this: > > > > > > Why? I absolutely do not understand why people are always objecting to > > > large stack-allocated arrays in userland code (sometimes with the > > > definition of "large" being as small as 2k for some folks). > > > > This is incredibly off-topic, but I'll bite. > > > > I should not have said "heap-allocated", I was actually referring to > > statically-allocated. > > > > The issues as I see them: > > > > 1. Such buffers exist during the entire program's lifetime even if they > > aren't actively used/needed by the program. With malloc(3) and friends, > > you're allocating memory dynamically, and you can free(3) when done with > > it, rather than just having a gigantic portion of memory allocated > > sitting around potentially doing nothing. > > > > 2. If the length of the buffer exceeds the amount of stack space > > available at the time, the program will run but the behaviour is unknown > > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > > the program segfaults at runtime). With malloc and friends you can > > gracefully handle allocation failures. > > > > 3. Statically-allocated buffers can't grow; meaning what you've > > requested size-wise is all you get. Compare this to something that's > > dynamic -- think a linked list containing pointers to malloc'd memory, > > which can even be realloc(3)'d if needed. > > > > The definition of what's "too large" is up to the individual and the > > limits of the underlying application. For some people, sure, anything > > larger than 2048 might warrant use of malloc. I tend to use malloc for > > anything larger than 4096. That "magic number" comes from some piece of > > information I was told long ago about what size pages malloc internally > > uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it > > appears to be a lot more complex than that. > > > > If you want me to break down #1 for you with some real-world output and > > a very small C program, showing you the effects on RES/RSS and SIZE/VIRT > > of static vs. dynamic allocation, just ask. > > > > Actually, after seeing that the userland limit for an unpriveleged user > on freebsd is a mere 64k, I'd say the only valid reason to not allocate > big things on the stack is because freebsd has completely broken > defaults. The limits (i.e. what's shown via limits(1)) differs per architecture (ex. i386 vs. amd64) and may adjust based on amount of physical memory available (not sure on the latter part). The "64k" value you're talking about, I think, is "memorylocked" -- I'm referring to "stacksize". > I see no reason why there should even be a distinction > between stack size and memory use limits in general. Pages are pages, > it really doesn't matter what part of your virtual address space they > live in. You're thinking purely of SIZE/VIRT. I guess I'd best break the C program out. Apologise in advance for the crappy code (system(3)!), but I wanted something that made the task easy. $ limits -a Resource limits (current): cputime infinity secs filesize infinity kB datasize 2621440 kB stacksize 262144 kB coredumpsize infinity kB memoryuse infinity kB memorylocked 64 kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB pseudo-terminals infinity swapuse infinity kB $ cat x.c #include #include #include #include #include #define SIZE_MFATTY 512*1024*1024 /* 512MB */ #define SIZE_SFATTY 128*1024*1024 /* 128MB; must be smaller than limits stacksize! */ int main(int argc, char *argv[]) { char procstat[BUFSIZ]; char topgrep[BUFSIZ]; pid_t mypid; char *mfatty; char sfatty[SIZE_SFATTY]; sfatty[0] = '\0'; /* squelch gcc unused var warning */ mypid = getpid(); snprintf(procstat, sizeof(procstat), "procstat -v %u", mypid); snprintf(topgrep, sizeof(topgrep), "top -b 99999 | egrep '^(Mem:|[ ]+PID|[ ]*%u)'", mypid); printf("at startup\n"); printf("============\n"); system(topgrep); printf("-----\n"); system(procstat); sleep(5); mfatty = malloc(SIZE_MFATTY); printf("\n"); printf("after malloc mfatty\n"); printf("=====================\n"); system(topgrep); printf("-----\n"); system(procstat); sleep(5); memset(mfatty, 0x0, SIZE_MFATTY); memset(&sfatty, 0x0, SIZE_SFATTY); printf("\n"); printf("after memset mfatty and sfatty\n"); printf(" (e.g. pages are marked used/written to)\n"); printf("===========================================\n"); system(topgrep); printf("-----\n"); system(procstat); sleep(5); free(mfatty); printf("\n"); printf("after free mfatty\n"); printf("===================\n"); system(topgrep); printf("-----\n"); system(procstat); return(0); } $ gcc -Wall -o x x.c $ ./x at startup ============ Mem: 97M Active, 221M Inact, 1530M Wired, 825M Buf, 6045M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 17567 jdc 1 27 0 138M 1524K wait 1 0:00 0.00% ./x ----- PID START END PRT RES PRES REF SHD FL TP PATH 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 2 0 1 0 C--D df 17567 0x7ffffffdf000 0x7ffffffff000 rw- 3 0 1 0 CN-- df 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph after malloc mfatty ===================== Mem: 97M Active, 221M Inact, 1530M Wired, 825M Buf, 6045M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 17567 jdc 1 25 0 650M 1524K wait 3 0:00 0.00% ./x ----- PID START END PRT RES PRES REF SHD FL TP PATH 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df 17567 0xa1000000 0xc1000000 rw- 0 0 1 0 CN-- df 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 2 0 1 0 C--D df 17567 0x7ffffffdf000 0x7ffffffff000 rw- 3 0 1 0 CN-- df 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph after memset mfatty and sfatty (e.g. pages are marked used/written to) =========================================== Mem: 737M Active, 221M Inact, 1531M Wired, 825M Buf, 5404M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 17567 jdc 1 31 0 650M 643M wait 2 0:01 5.27% ./x ----- PID START END PRT RES PRES REF SHD FL TP PATH 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df 17567 0xa1000000 0xc1000000 rw- 131072 0 1 0 CNS- df 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 32739 0 1 0 C-SD df 17567 0x7ffffffdf000 0x7ffffffff000 rw- 32 0 1 0 CN-- df 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph after free mfatty =================== Mem: 229M Active, 222M Inact, 1531M Wired, 825M Buf, 5913M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 17567 jdc 1 27 0 138M 130M wait 3 0:01 2.78% ./x ----- PID START END PRT RES PRES REF SHD FL TP PATH 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df 17567 0xa0600000 0xa0618000 r-x 24 0 38 0 CN-- vn /libexec/ld-elf.so.1 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df 17567 0xa081a000 0xa094b000 r-x 283 0 65 27 CN-- vn /lib/libc.so.7 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 32739 0 1 0 C-SD df 17567 0x7ffffffdf000 0x7ffffffff000 rw- 32 0 1 0 CN-- df 17567 0x7ffffffff000 0x800000000000 r-x 0 0 41 0 CN-- ph Look very carefully at the RES column for that process, particularly after the memset(), and then again after the free(). You'll see quite clearly that the sfatty[] array remains in use, wasting memory that could otherwise be used by other processes on the system, up until exit. This is also quite apparent in the procstat output. Moral of the story: it matters (and malloc is your friend). :-) > Almost everything I've ever done with freebsd runs as root on an > embedded system, so I'm not used to thinking in terms of limits at all. I would think an embedded platform would do the exact opposite -- force you to think in terms of limits *all the time*. For example: I partake in the TomatoUSB project (a Linux-based firmware that runs mainly on MIPSR1/R2 boxes); my overall thought process. when developing or fixing something relating to TomatoUSB are significantly more strict than on a FreeBSD amd64 system with 8GB RAM and an 8-core CPU. But generally speaking I tend to write code/develop things with "minimal" in mind at all times, and that all stems from growing up doing assembly on 65xxx systems (Apple II series, Nintendo/Famicom and the Super Nintendo/Super Famicom) and PIC -- where CPU time and memory is highly limits. I always design things assuming it'll be used on very minimal architectures. I am in no way saying John (or you!) should have the same mentality (like I said it varies on environment and application goal and so on), but with regards to what I do, KISS principle combined with "minimalist" approach has yet to fail me. But there are certainly cases with complex applications where you can't design something within those limits (e.g. "okay, to do this efficiently, we're going to need to have about 128MBytes of non-swapped RAM available just for this process at all times"), and I respect that. But my point is that static allocation vs. malloc matters more than you think. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 00:28:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 35F37828 for ; Mon, 25 Feb 2013 00:28:58 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id E1CCDFE2 for ; Mon, 25 Feb 2013 00:28:57 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 2B248450CE; Mon, 25 Feb 2013 00:28:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.7.4 isis.morrow.me.uk 2B248450CE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1361752135; bh=43Mp0h844cIux3EZu/0Z964JKHBymPbJTc93SXjbto0=; h=Date:From:To:Subject:References:In-Reply-To; b=osDlafs4Pdl4dIP/kf7mDDxobR0arSIlU8NIrKBaCQvmWF71PBBZ2XcFtt3OMSB7w LLeVA1XoIvh9yyqtMcu5lHgCJqZP9enqShAVg1bWBQQJmlkgvd8+RiStQC6bHr0rYh xgaz6U97pWpP0GxBf+t/AUQbrSd97Xn4XyaT6Wvg= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id E5A7D9240; Mon, 25 Feb 2013 00:28:51 +0000 (GMT) Date: Mon, 25 Feb 2013 00:28:51 +0000 From: Ben Morrow To: jdc@koitsu.org, freebsd-stable@freebsd.org Subject: Re: svn - but smaller? Message-ID: <20130225002847.GA42160@anubis.morrow.me.uk> References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130224212436.GA13670@icarus.home.lan> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 00:28:58 -0000 Quoth Jeremy Chadwick : > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > bytes). I'm referring to this: > > > > Why? I absolutely do not understand why people are always objecting to > > large stack-allocated arrays in userland code (sometimes with the > > definition of "large" being as small as 2k for some folks). > > This is incredibly off-topic, but I'll bite. > > I should not have said "heap-allocated", I was actually referring to > statically-allocated. > > The issues as I see them: > > 1. Such buffers exist during the entire program's lifetime even if they > aren't actively used/needed by the program. With malloc(3) and friends, > you're allocating memory dynamically, and you can free(3) when done with > it, rather than just having a gigantic portion of memory allocated > sitting around potentially doing nothing. If the 'allocated' memory isn't touched, it will never be paged in. Even once it is paged in, if it then goes back to being unused it can be paged out to swap (when necessary) and then stay there. (It would be nice if there were some way to tell the system 'this memory is dead, don't write it out to swap', but I don't think there is.) Of course, you may get up to two pages of an object paged in just because some other object on the same page was touched, but 'two pages' is not a lot of memory to waste (especially given that you're saving the malloc overhead). I don't know if the compiler is clever enough to page-align large static allocations; that would reduce the potential waste to one page. > 2. If the length of the buffer exceeds the amount of stack space > available at the time, the program will run but the behaviour is unknown > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > the program segfaults at runtime). With malloc and friends you can > gracefully handle allocation failures. (SIGSEGV on stack overflow is specified by POSIX, including the fact that the signal must be fatal unless the signal handler uses an alternate stack.) Statically-allocated objects are not allocated on the stack, they are allocated in the bss or data sections of the executable. When it is possible and reasonable to do so, it's actually better to allocate all memory statically, as then once the process has started successfully you can be certain it won't fail because of a memory shortage. Large auto objects (including alloca) *are* dangerous. > 3. Statically-allocated buffers can't grow; meaning what you've > requested size-wise is all you get. Compare this to something that's > dynamic -- think a linked list containing pointers to malloc'd memory, > which can even be realloc(3)'d if needed. Under many circumstances a statically-allocated fixed-size buffer, *if properly used*, is safer than a potentially-unbounded malloced one. Of course, it's possible to put limits on the size of a malloced buffer as well, but (given that parts of the buffer you don't use won't ever be paged in) there isn't much advantage in doing so. Fixed allocations are only useful in small, single-use programs where you can accurately predict the memory requirements in advance. I wouldn't be surprised if svnsup fell into that bracket. Ben From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 01:50:29 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56411491 for ; Mon, 25 Feb 2013 01:50:29 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 26F83349 for ; Mon, 25 Feb 2013 01:50:28 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r1P1eeuS017218; Sun, 24 Feb 2013 17:40:44 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201302250140.r1P1eeuS017218@gw.catspoiler.org> Date: Sun, 24 Feb 2013 17:40:40 -0800 (PST) From: Don Lewis Subject: Re: RELENG_8: amdtemp module and newer CPUs not working. MFC? To: jdc@koitsu.org In-Reply-To: <20130221072339.GA74725@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org, torfinn.ingolfsen@getmail.no X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 01:50:29 -0000 On 20 Feb, Jeremy Chadwick wrote: > On Wed, Feb 20, 2013 at 10:29:05PM -0800, Don Lewis wrote: >> On 17 Feb, Torfinn Ingolfsen wrote: >> > Hello, >> > I'm running FreeBSD 8.3-stable on a machine with an AMD A8-5600K cpu. >> > tingo@kg-quiet$ uname -a >> > FreeBSD kg-quiet.kg4.no 8.3-STABLE FreeBSD 8.3-STABLE #2: Fri Jan 4 19:18:15 CET 2013 >> > root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 >> > tingo@kg-quiet$ dmesg | grep CPU | head -1 >> > CPU: AMD A8-5600K APU with Radeon(tm) HD Graphics (3618.02-MHz K8-class CPU) >> > >> > Unfortunately, the amdtemp.ko module doesn't work: >> > tingo@kg-quiet$ kldstat | grep temp >> > 10 1 0xffffffff8123e000 f0f amdtemp.ko >> > tingo@kg-quiet$ sysctl dev.amdtemp >> > sysctl: unknown oid 'dev.amdtemp' >> > >> > Based on a thread[1] on the forums, amdtemp.c from -CURRENT work. >> > But it doesn't compile under FreeBSD 8.3-stable: >> >> Updating amdtemp is on my TODO list. It has some issues even on >> -CURRENT. This is kind of far down my priority list because on most of >> my AMD machines, I can also get the temperature without amdtemp: >> >> % sysctl hw.acpi.thermal.tz0.temperature >> hw.acpi.thermal.tz0.temperature: 30.0C > > There's an implication in your statement here, so I want to clarify for > readers (as the author of sysutils/bsdhwmon): > > acpi_thermal(4) does not necessarily "tie in" to an on-die DTS within > the CPU. Your motherboards and CPUs (both matter! (e.g. for Intel CPUs, > see PECI (not a typo)) may offer this tie-in, but such is not the case > for many people. I tend to find ACPI thermal zones used in laptops and > very rarely anywhere else. > > acpi_thermal(4) may return temperatures from zones that are mapped to > readings from Super I/O chips or dedicated H/W monitoring ICs (such as > ones provided by Nuvuton/Winbond, LM, ITE, ADT, etc.). It all depends > on how the BIOSes ACPI tables are written/what maps to what. > > Such ICs DO NOT have anything to do with the on-die DTS which both > amdtemp(4) and coretemp(4) use -- instead, these chips use external > thermistors which may be placed anywhere on the motherboard (such as > under the CPU socket, or wherever the manufacturer chooses (and more > often than not, does not document)). > > My point: under the CPU thermistor != within the CPU DTS. They measure > two different things, and are not guaranteed to be even remotely > similar. I can show proof of this (a very large delta between Core i5 > core DTSes and an on-board IT87xxx) if requested. You are correct. It had been several months since I looked at this and was misremembering the details. With amdtemp loaded on one of my systems where it works: hw.acpi.thermal.tz0.temperature: 34.0C dev.cpu.0.temperature: 37.2C dev.cpu.1.temperature: 42.2C dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb3 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 37.5C dev.amdtemp.0.core0.sensor1: 32.7C dev.amdtemp.0.core1.sensor0: 42.2C dev.amdtemp.0.core1.sensor1: 28.2C When I looked at this previously (on another system with only one DTS), I noticed that dev.amdtemp.0.core0.sensor0 was giving the same answer as dev.cpu.0.temperature. I was unaware that amdtemp was responsible for both sysctl nodes and thought that some other kernel driver was responsible for dev.cpu.0.temperature, which is why I stopped work on my amdtemp updates. I see that the amdtemp(4) man page explains the situation. Thanks for the heads up about sysutils/bsdhwmon. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 03:25:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9CACD505 for ; Mon, 25 Feb 2013 03:25:48 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3589F3 for ; Mon, 25 Feb 2013 03:25:47 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r1P3Plgq054238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2013 19:25:47 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r1P3PlkP054237; Sun, 24 Feb 2013 19:25:47 -0800 (PST) (envelope-from jmg) Date: Sun, 24 Feb 2013 19:25:47 -0800 From: John-Mark Gurney To: Ben Morrow Subject: Re: svn - but smaller? Message-ID: <20130225032546.GL55866@funkthat.com> Mail-Followup-To: Ben Morrow , jdc@koitsu.org, freebsd-stable@freebsd.org References: <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130225002847.GA42160@anubis.morrow.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130225002847.GA42160@anubis.morrow.me.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 24 Feb 2013 19:25:47 -0800 (PST) Cc: jdc@koitsu.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 03:25:48 -0000 Ben Morrow wrote this message on Mon, Feb 25, 2013 at 00:28 +0000: > > 1. Such buffers exist during the entire program's lifetime even if they > > aren't actively used/needed by the program. With malloc(3) and friends, > > you're allocating memory dynamically, and you can free(3) when done with > > it, rather than just having a gigantic portion of memory allocated > > sitting around potentially doing nothing. > > If the 'allocated' memory isn't touched, it will never be paged in. Even > once it is paged in, if it then goes back to being unused it can be > paged out to swap (when necessary) and then stay there. (It would be > nice if there were some way to tell the system 'this memory is dead, > don't write it out to swap', but I don't think there is.) madvise(2) w/ MADV_FREE, though there was some discussion on -current about what these different flags will/should do not too long ago... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 08:10:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0312EDBE for ; Mon, 25 Feb 2013 08:10:51 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E105A34F for ; Mon, 25 Feb 2013 08:10:50 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (173-14-202-177-fresno.hfc.comcastbusiness.net [173.14.202.177]) by elvis.mu.org (Postfix) with ESMTPSA id BC5AE1A3CD0; Mon, 25 Feb 2013 00:04:42 -0800 (PST) Message-ID: <512B1B19.3000207@mu.org> Date: Mon, 25 Feb 2013 00:04:41 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mark Atkinson Subject: Re: watchdogs References: <512525C1.1070502@norma.perm.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 08:10:51 -0000 On 2/22/13 8:47 AM, Mark Atkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/20/2013 11:36, Eugene M. Zheganin wrote: >> Hi. >> >> I have a bunch of FreeBSDs that hangs (and I really want to do >> something to fight this). May be it's the zfs or may be it's the pf >> (I also have a bunch of really stable ones, so it's hard to isolate >> and tell). Since 9.x hang more often I suppose it's pf. I use >> ichwd.ko and watchdogd to reboot a machine when it hangs. It works >> pretty well; I'm also working on a various WITNESS/INVARIANTS stuff >> and I'm trying to report it to gnats, but obviously it would be >> much nicer if the system would panic and leave some debuggable core >> after a hang (so far I don't have any, so I can only guess). I've >> read about software watchdog in kernel and I doesn'y quite >> understand: it's said that kernel software watchdog is able to >> panic when a deadlock occurs. Can this be achieved with ichwd ? >> Another one: as far as I understand ichwd reboots my machine on a >> hardware level, right ? So am I right saying that software watchdog >> can be, in theory, also deadlocked, thus, being kinda less reliable >> solution ? > I just want to /metoo that I have 32bit/i386 box running zfs, pf and > - -current that is hardlocking randomly (usually has an uptime for a few > days to a couple weeks). SW_WATCHDOG won't fire when it locks so it > must be locking pretty fast. > > I just noticed that ichwd will load on this box, so I'll try that > instead, but now I'm wondering if the SW_WATCHDOG kernel will > interfere or rather if watchdogd is smart enough to handle both? watchdog(4) will arm all watchdogs. watchdogd uses watchdog(4) so yes, both watchdogs (SW_WATCHDOG & ichwd) should be armed. > > This box used to occasionally panic on the ZFS stack panic so I did > the KSTACK_PAGES=4 change to the kernel and now it just hardlocks. > I'm not saying they are related. Interesting. What is the default for KSTACK_PAGES? Btw, from all I've heard less than 4GB ram + ZFS == you're gonna have a bad time. There are supposedly some ways to make it somewhat reliable by disabling certain features, but I don't know the tricks off hand. -Alfred From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 14:31:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D52EB47F for ; Mon, 25 Feb 2013 14:31:32 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx1.freebsd.org (Postfix) with ESMTP id 73842FC1 for ; Mon, 25 Feb 2013 14:31:32 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id db10so2197214veb.37 for ; Mon, 25 Feb 2013 06:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gwvfPd8maSUf3njaz9NfNJtzk+H9yc6Dw0BbK/IrL3g=; b=AGfU+kTztmDgOVYE5WJm7SXd7NdSsCYfJf288Es4nL5VNbgo3mKCGGwBLXeAVPqr12 qayeBGb4J+oilN1bBV5Fg7nL5aLJT7pw49qw4nYAeJhhYVpB6ugVXZ+b76qSb73vuRJc TFXcLIH7p+rJa0pNDKBI39D7eYIiRA+Tg1KsqlK++3OX4ZhKw7SWFL45Mq5ApwIxkhLp MfQtKgyuOjfwBtvn0VsbbFfg9SpFjeY0hweV8aBg5ozH+Nt+n0otAAQrBYkuCtFjXTg3 9DXgsoshDHQTqmit5/6PWRVXM1rJZ5Sy3FPKQ8SqrqmTBTRater8aIOup3GBKf7DTiSL Uaqw== MIME-Version: 1.0 X-Received: by 10.220.220.134 with SMTP id hy6mr9883588vcb.2.1361802686297; Mon, 25 Feb 2013 06:31:26 -0800 (PST) Received: by 10.58.100.147 with HTTP; Mon, 25 Feb 2013 06:31:26 -0800 (PST) In-Reply-To: <20130124174039.GA35811@icarus.home.lan> References: <20130124174039.GA35811@icarus.home.lan> Date: Mon, 25 Feb 2013 14:31:26 +0000 Message-ID: Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 14:31:32 -0000 On Thu, Jan 24, 2013 at 5:40 PM, Jeremy Chadwick wrote: >>> #1. Map the physical drive slots to how they show up in FBSD so if a >>> disk is removed and the machine is rebooted all the disks after that >>> removed one do not have an 'off by one error'. i.e. if you have >>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >>> missing ada8 drive and the next drive (that used to be ada9) is now >>> called ada8 and so on... >> >>How do you do that? If I'm in that situation, I think I could find the >>bad drive, or at least the good ones, with diskinfo and the drive serial >>number. One suggestion I saw somewhere was to use disk serial numbers >>for label values. > > The term FreeBSD uses for this is called "wiring down" or "wired down", > and is documented in CAM(4). It's come up repeatedly over the years but > for whatever reason people overlook it or can't find it. Here's how you > do it for Intel AHCI (and probably others like AMD), taken directly from > my /boot/loader.conf -- > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" > > IMPORTANT: The device names/busses/etc. are going to vary depending on > each person's setup, controller, etc.. Proof of this is in a post from > Randy Bush, where I helped him off-list with this task and he figured > out the remaining bits by himself for his hptrr(4) controller: > > http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html > This wiring down is not sufficient to address all the problems with drive renumbering. For instance, add an additional ahci controller, and potentially all your drive names change again. Or not, depending on how the devices are enumerated. This is not the only problem. Take all the disks out, put them all back in, do they all have the same names? Unlikely, since their name is now derived from the controller and port they are plugged in to. Any changes, and the device name changes. Using GPT labels is easy to do, and provides a cast iron guarantee that your disk will not EVER be mistaken for a different drive. I put a GPT label on the drive, and then write it in permanent marker on the top of the drive and on a sticky label that is stuck on the front of the chassis. The disk label never changes in its lifetime, so you only get issues if you insert a drive without labelling it first. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 14:50:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4104CFF for ; Mon, 25 Feb 2013 14:50:45 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6A29B179 for ; Mon, 25 Feb 2013 14:50:45 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so3023574oag.15 for ; Mon, 25 Feb 2013 06:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=IqZ14HVxMRtPQoYK/JMdMwYBIwk1PZ+GB9zGSPRM9gI=; b=ryjIw1m0XI7OK7TX83ZZmT78ouKs2+ilEvWx4DOnDr9PdGzvrZyfUVb97wNpxm5qKD KH5Mn73oWDq6T1FYvjdSMH616czxfKCOSrX4sHGlF7bRvb/NegZWqIV7TgnAxKz9a0pX 9QAC4zD0y8lPPNYeJ1EXStH4iLQrhjOK0g5Y3lmPdFM4rUGS2qbp2VCtZgHuVyKuzSox 1Qt9+QHd27URuvwxngIQG0qf0zZNMZlvjmnl/Rd3vilcZF/DKckgwMHwg+OTC6VyPzY8 A0+/9UH70UClKsAI4l+nNw0WHdO1W+yi6fsd0v1W7zNmwPRTwfUujC9CcDwg1xXbyi07 GT6A== X-Received: by 10.60.169.212 with SMTP id ag20mr7707810oec.102.1361803844878; Mon, 25 Feb 2013 06:50:44 -0800 (PST) Received: from guysmbp.dyn.palisadesys.com ([216.81.189.10]) by mx.google.com with ESMTPS id ka6sm13580358obb.3.2013.02.25.06.50.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 06:50:43 -0800 (PST) From: Guy Helmer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: =?windows-1252?Q?Re=3A_syslogd_spinning_the_CPU=2C_not_logging?= =?windows-1252?Q?=85?= Message-Id: Date: Mon, 25 Feb 2013 08:50:45 -0600 To: mi+thun@aldan.algebra.com, FreeBSD Stable Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 14:50:45 -0000 Regarding a message of yours from a May 2011, I have an 8.3 i386 system = where syslogd has been found spinning the CPU a few times in the past = week.=20 The stack trace is similar to yours: #0 0x4810cfa9 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #1 0x4810f890 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #2 0x48116bbe in free () from /lib/libc.so.7 #3 0x0804c7e6 in init () #4 #5 0x48194af3 in select () from /lib/libc.so.7 #6 0x0804e147 in main () On this system, syslogd is configured with a pipe to sshguard to monitor = failed logins. In my searches, I have not noticed any resolution for this issue -- any = chance I've missed one? Thanks, Guy From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 15:54:44 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9368DB56 for ; Mon, 25 Feb 2013 15:54:44 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 485FF684 for ; Mon, 25 Feb 2013 15:54:44 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UA0O2-000KF5-Hf; Mon, 25 Feb 2013 15:54:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1PFsdjR080856; Mon, 25 Feb 2013 08:54:39 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/3iYbAdSA6/AMKiOMnhC27 Subject: Re: svn - but smaller? From: Ian Lepore To: Jeremy Chadwick In-Reply-To: <20130225000454.GA17342@icarus.home.lan> References: <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> <1361749413.16937.16.camel@revolution.hippie.lan> <20130225000454.GA17342@icarus.home.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Feb 2013 08:54:39 -0700 Message-ID: <1361807679.16937.61.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 15:54:44 -0000 On Sun, 2013-02-24 at 16:04 -0800, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 04:43:33PM -0700, Ian Lepore wrote: > > On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > > > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > > > bytes). I'm referring to this: > > > > > > > > Why? I absolutely do not understand why people are always objecting to > > > > large stack-allocated arrays in userland code (sometimes with the > > > > definition of "large" being as small as 2k for some folks). > > > > > > This is incredibly off-topic, but I'll bite. > > > > > > I should not have said "heap-allocated", I was actually referring to > > > statically-allocated. > > > > > > The issues as I see them: > > > > > > 1. Such buffers exist during the entire program's lifetime even if they > > > aren't actively used/needed by the program. With malloc(3) and friends, > > > you're allocating memory dynamically, and you can free(3) when done with > > > it, rather than just having a gigantic portion of memory allocated > > > sitting around potentially doing nothing. > > > > > > 2. If the length of the buffer exceeds the amount of stack space > > > available at the time, the program will run but the behaviour is unknown > > > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > > > the program segfaults at runtime). With malloc and friends you can > > > gracefully handle allocation failures. > > > > > > 3. Statically-allocated buffers can't grow; meaning what you've > > > requested size-wise is all you get. Compare this to something that's > > > dynamic -- think a linked list containing pointers to malloc'd memory, > > > which can even be realloc(3)'d if needed. > > > > > > The definition of what's "too large" is up to the individual and the > > > limits of the underlying application. For some people, sure, anything > > > larger than 2048 might warrant use of malloc. I tend to use malloc for > > > anything larger than 4096. That "magic number" comes from some piece of > > > information I was told long ago about what size pages malloc internally > > > uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it > > > appears to be a lot more complex than that. > > > > > > If you want me to break down #1 for you with some real-world output and > > > a very small C program, showing you the effects on RES/RSS and SIZE/VIRT > > > of static vs. dynamic allocation, just ask. > > > > > > > Actually, after seeing that the userland limit for an unpriveleged user > > on freebsd is a mere 64k, I'd say the only valid reason to not allocate > > big things on the stack is because freebsd has completely broken > > defaults. > > The limits (i.e. what's shown via limits(1)) differs per architecture > (ex. i386 vs. amd64) and may adjust based on amount of physical memory > available (not sure on the latter part). The "64k" value you're talking > about, I think, is "memorylocked" -- I'm referring to "stacksize". > > > I see no reason why there should even be a distinction > > between stack size and memory use limits in general. Pages are pages, > > it really doesn't matter what part of your virtual address space they > > live in. > > You're thinking purely of SIZE/VIRT. > > I guess I'd best break the C program out. Apologise in advance for the > crappy code (system(3)!), but I wanted something that made the task > easy. > > $ limits -a > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 2621440 kB > stacksize 262144 kB > coredumpsize infinity kB > memoryuse infinity kB > memorylocked 64 kB > maxprocesses 5547 > openfiles 11095 > sbsize infinity bytes > vmemoryuse infinity kB > pseudo-terminals infinity > swapuse infinity kB > > $ cat x.c > #include > #include > #include > #include > #include > > #define SIZE_MFATTY 512*1024*1024 /* 512MB */ > #define SIZE_SFATTY 128*1024*1024 /* 128MB; must be smaller than limits stacksize! */ > > int main(int argc, char *argv[]) { > char procstat[BUFSIZ]; > char topgrep[BUFSIZ]; > pid_t mypid; > char *mfatty; > char sfatty[SIZE_SFATTY]; > > sfatty[0] = '\0'; /* squelch gcc unused var warning */ > > mypid = getpid(); > > snprintf(procstat, sizeof(procstat), > "procstat -v %u", mypid); > snprintf(topgrep, sizeof(topgrep), > "top -b 99999 | egrep '^(Mem:|[ ]+PID|[ ]*%u)'", mypid); > > printf("at startup\n"); > printf("============\n"); > system(topgrep); > printf("-----\n"); > system(procstat); > sleep(5); > > mfatty = malloc(SIZE_MFATTY); > printf("\n"); > printf("after malloc mfatty\n"); > printf("=====================\n"); > system(topgrep); > printf("-----\n"); > system(procstat); > sleep(5); > > memset(mfatty, 0x0, SIZE_MFATTY); > memset(&sfatty, 0x0, SIZE_SFATTY); > printf("\n"); > printf("after memset mfatty and sfatty\n"); > printf(" (e.g. pages are marked used/written to)\n"); > printf("===========================================\n"); > system(topgrep); > printf("-----\n"); > system(procstat); > sleep(5); > > free(mfatty); > printf("\n"); > printf("after free mfatty\n"); > printf("===================\n"); > system(topgrep); > printf("-----\n"); > system(procstat); > > return(0); > } > > $ gcc -Wall -o x x.c > $ ./x > at startup > ============ > Mem: 97M Active, 221M Inact, 1530M Wired, 825M Buf, 6045M Free > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 17567 jdc 1 27 0 138M 1524K wait 1 0:00 0.00% ./x > ----- > PID START END PRT RES PRES REF SHD FL TP PATH > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 2 0 1 0 C--D df > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 3 0 1 0 CN-- df > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph > > after malloc mfatty > ===================== > Mem: 97M Active, 221M Inact, 1530M Wired, 825M Buf, 6045M Free > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 17567 jdc 1 25 0 650M 1524K wait 3 0:00 0.00% ./x > ----- > PID START END PRT RES PRES REF SHD FL TP PATH > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > 17567 0xa1000000 0xc1000000 rw- 0 0 1 0 CN-- df > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 2 0 1 0 C--D df > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 3 0 1 0 CN-- df > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph > > after memset mfatty and sfatty > (e.g. pages are marked used/written to) > =========================================== > Mem: 737M Active, 221M Inact, 1531M Wired, 825M Buf, 5404M Free > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 17567 jdc 1 31 0 650M 643M wait 2 0:01 5.27% ./x > ----- > PID START END PRT RES PRES REF SHD FL TP PATH > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > 17567 0xa1000000 0xc1000000 rw- 131072 0 1 0 CNS- df > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 32739 0 1 0 C-SD df > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 32 0 1 0 CN-- df > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph > > after free mfatty > =================== > Mem: 229M Active, 222M Inact, 1531M Wired, 825M Buf, 5913M Free > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 17567 jdc 1 27 0 138M 130M wait 3 0:01 2.78% ./x > ----- > PID START END PRT RES PRES REF SHD FL TP PATH > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > 17567 0xa0600000 0xa0618000 r-x 24 0 38 0 CN-- vn /libexec/ld-elf.so.1 > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > 17567 0xa081a000 0xa094b000 r-x 283 0 65 27 CN-- vn /lib/libc.so.7 > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 32739 0 1 0 C-SD df > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 32 0 1 0 CN-- df > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 41 0 CN-- ph > > Look very carefully at the RES column for that process, particularly > after the memset(), and then again after the free(). > > You'll see quite clearly that the sfatty[] array remains in use, wasting > memory that could otherwise be used by other processes on the system, up > until exit. This is also quite apparent in the procstat output. > > Moral of the story: it matters (and malloc is your friend). :-) > > > Almost everything I've ever done with freebsd runs as root on an > > embedded system, so I'm not used to thinking in terms of limits at all. > > I would think an embedded platform would do the exact opposite -- force > you to think in terms of limits *all the time*. > > For example: I partake in the TomatoUSB project (a Linux-based firmware > that runs mainly on MIPSR1/R2 boxes); my overall thought process. when > developing or fixing something relating to TomatoUSB are significantly > more strict than on a FreeBSD amd64 system with 8GB RAM and an 8-core CPU. > > But generally speaking I tend to write code/develop things with > "minimal" in mind at all times, and that all stems from growing up doing > assembly on 65xxx systems (Apple II series, Nintendo/Famicom and the > Super Nintendo/Super Famicom) and PIC -- where CPU time and memory is > highly limits. I always design things assuming it'll be used on very > minimal architectures. > > I am in no way saying John (or you!) should have the same mentality > (like I said it varies on environment and application goal and so on), > but with regards to what I do, KISS principle combined with "minimalist" > approach has yet to fail me. But there are certainly cases with complex > applications where you can't design something within those limits (e.g. > "okay, to do this efficiently, we're going to need to have about > 128MBytes of non-swapped RAM available just for this process at all > times"), and I respect that. But my point is that static allocation > vs. malloc matters more than you think. > So your point is that if a program is going to call deep down into some chain that uses big stack-allocated buffers, then it continues to run for some non-trivial amount of time after that, never again descending that particular call chain, then the memory would have been recovered by the system faster if it had been malloc'd and free'd rather than stack allocated. But if the program uses the big buffers for most of its duration, then there's no real difference in behavior at all. If the big buffers are smaller than the limit within the malloc implementation that triggers a MADV_DONTNEED immediately, (for example, if they were less than... I think it's 4MB in our current implementation) then there's no real difference. I'm guessing you had to use such extreme sized buffers to demonstrate your point because with something more reasonable (we were talking about ~200K of IO buffers originally) there was no difference. I guess the moral of the story is don't use huge stack-allocated buffers once at startup in a daemon, especially if megabytes are involved. But if you're writing some normal program that needs some memory for a while for its major tasks, and when its done with those tasks it exits, then... there's no real difference. Which I guess means the real bottom-line moral of the story is that there are no simple mantras. "Don't use big stack allocated buffers" is going to be wrong as many times as "Always allocate everything on the stack" -- you can come up with examples that refute each assertion. -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 16:51:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 29644EE9 for ; Mon, 25 Feb 2013 16:51:07 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id D03178B8 for ; Mon, 25 Feb 2013 16:51:06 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r1PGiWCk072301 for ; Mon, 25 Feb 2013 10:44:33 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Mon Feb 25 10:44:33 2013 Message-ID: <512B94EB.30201@denninger.net> Date: Mon, 25 Feb 2013 10:44:27 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Tom Evans Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD References: <20130124174039.GA35811@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130225-0, 02/25/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 16:51:07 -0000 On 2/25/2013 8:31 AM, Tom Evans wrote: > On Thu, Jan 24, 2013 at 5:40 PM, Jeremy Chadwick wrote: >>>> #1. Map the physical drive slots to how they show up in FBSD so if a >>>> disk is removed and the machine is rebooted all the disks after that >>>> removed one do not have an 'off by one error'. i.e. if you have >>>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that >>>> missing ada8 drive and the next drive (that used to be ada9) is now >>>> called ada8 and so on... >>> How do you do that? If I'm in that situation, I think I could find the >>> bad drive, or at least the good ones, with diskinfo and the drive serial >>> number. One suggestion I saw somewhere was to use disk serial numbers >>> for label values. >> The term FreeBSD uses for this is called "wiring down" or "wired down", >> and is documented in CAM(4). It's come up repeatedly over the years but >> for whatever reason people overlook it or can't find it. Here's how you >> do it for Intel AHCI (and probably others like AMD), taken directly from >> my /boot/loader.conf -- >> >> # "Wire down" device names (ada[0-5]) to each individual port >> # on the SATA/AHCI controller. This ensures that if we reboot >> # with a disk missing, the device names stay the same, and stay >> # attached to the same SATA/AHCI controller. >> # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html >> # >> hint.scbus.0.at="ahcich0" >> hint.scbus.1.at="ahcich1" >> hint.scbus.2.at="ahcich2" >> hint.scbus.3.at="ahcich3" >> hint.scbus.4.at="ahcich4" >> hint.scbus.5.at="ahcich5" >> hint.ada.0.at="scbus0" >> hint.ada.1.at="scbus1" >> hint.ada.2.at="scbus2" >> hint.ada.3.at="scbus3" >> hint.ada.4.at="scbus4" >> hint.ada.5.at="scbus5" >> >> IMPORTANT: The device names/busses/etc. are going to vary depending on >> each person's setup, controller, etc.. Proof of this is in a post from >> Randy Bush, where I helped him off-list with this task and he figured >> out the remaining bits by himself for his hptrr(4) controller: >> >> http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html >> > This wiring down is not sufficient to address all the problems with > drive renumbering. For instance, add an additional ahci controller, > and potentially all your drive names change again. Or not, depending > on how the devices are enumerated. > > This is not the only problem. Take all the disks out, put them all > back in, do they all have the same names? Unlikely, since their name > is now derived from the controller and port they are plugged in to. > Any changes, and the device name changes. > > Using GPT labels is easy to do, and provides a cast iron guarantee > that your disk will not EVER be mistaken for a different drive. > > I put a GPT label on the drive, and then write it in permanent marker > on the top of the drive and on a sticky label that is stuck on the > front of the chassis. The disk label never changes in its lifetime, so > you only get issues if you insert a drive without labelling it first. > > Cheers > > Tom > Listen to this man. Either do it in gpart or do it with glabel (depending on where you want it to show up); once done the drive will always have the same name in the device tree no matter what slot it shows up in. Then stick that label on the front of the drive carrier, and you never have this problem. Do that or suffer. Your choice. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 18:47:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6370AFC for ; Mon, 25 Feb 2013 18:47:46 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id B600AEA8 for ; Mon, 25 Feb 2013 18:47:46 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 4gvo1l0040vp7WLAEinmhS; Mon, 25 Feb 2013 18:47:46 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta05.emeryville.ca.mail.comcast.net with comcast id 4inl1l00P1t3BNj8Rinlzh; Mon, 25 Feb 2013 18:47:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2A7DD73A1C; Mon, 25 Feb 2013 10:47:45 -0800 (PST) Date: Mon, 25 Feb 2013 10:47:45 -0800 From: Jeremy Chadwick To: Tom Evans Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD Message-ID: <20130225184745.GA36717@icarus.home.lan> References: <20130124174039.GA35811@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361818066; bh=HwmnL2EYV/EUvG5Frs7uuV+HHdX27gdb0XTOL4O4zGw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=BvSF/DcqdpTqjqru7zrlm6GeTEtl3FIRHKCLD+XBFmUzYmFJYi/c0TTXoYsBpt9mm St8EnoT5lCHgAclEJcdwShE//Z67iMNW09i73H35YkpvoBA0w01eXr4s++Xkd8MWPA uxr1z5cEwF42EQu0O4wv2lQ5CRreejK/qAIhZF5daJbiwGB+GMeV5+glrilhH/GUz8 3am3YzsyaFcE4w98+Btje4h5Z3Ga4gKDEJhkELZM9gWmie8EaB95YuN24r/Lsjz75o MRXhpL3EGfBxu+psopKKftkx33xu2gW8lhu8ZNHYQrHjOKvj4juMi8K1uP0NaolBMp LBH8HjF4mdrlA== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 18:47:47 -0000 On Mon, Feb 25, 2013 at 02:31:26PM +0000, Tom Evans wrote: > On Thu, Jan 24, 2013 at 5:40 PM, Jeremy Chadwick wrote: > >>> #1. Map the physical drive slots to how they show up in FBSD so if a > >>> disk is removed and the machine is rebooted all the disks after that > >>> removed one do not have an 'off by one error'. i.e. if you have > >>> ada0-ada14 and remove ada8 then reboot - normally FBSD skips that > >>> missing ada8 drive and the next drive (that used to be ada9) is now > >>> called ada8 and so on... > >> > >>How do you do that? If I'm in that situation, I think I could find the > >>bad drive, or at least the good ones, with diskinfo and the drive serial > >>number. One suggestion I saw somewhere was to use disk serial numbers > >>for label values. > > > > The term FreeBSD uses for this is called "wiring down" or "wired down", > > and is documented in CAM(4). It's come up repeatedly over the years but > > for whatever reason people overlook it or can't find it. Here's how you > > do it for Intel AHCI (and probably others like AMD), taken directly from > > my /boot/loader.conf -- > > > > # "Wire down" device names (ada[0-5]) to each individual port > > # on the SATA/AHCI controller. This ensures that if we reboot > > # with a disk missing, the device names stay the same, and stay > > # attached to the same SATA/AHCI controller. > > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > > # > > hint.scbus.0.at="ahcich0" > > hint.scbus.1.at="ahcich1" > > hint.scbus.2.at="ahcich2" > > hint.scbus.3.at="ahcich3" > > hint.scbus.4.at="ahcich4" > > hint.scbus.5.at="ahcich5" > > hint.ada.0.at="scbus0" > > hint.ada.1.at="scbus1" > > hint.ada.2.at="scbus2" > > hint.ada.3.at="scbus3" > > hint.ada.4.at="scbus4" > > hint.ada.5.at="scbus5" > > > > IMPORTANT: The device names/busses/etc. are going to vary depending on > > each person's setup, controller, etc.. Proof of this is in a post from > > Randy Bush, where I helped him off-list with this task and he figured > > out the remaining bits by himself for his hptrr(4) controller: > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014522.html > > This wiring down is not sufficient to address all the problems with > drive renumbering. For instance, add an additional ahci controller, > and potentially all your drive names change again. Or not, depending > on how the devices are enumerated. Go read CAM(4). You can solve this dilemma using the wire-down method as well. I don't know how many times I have to say this. You really can solve the problem with the adaX, daX, or scbusX numbers changing if you add a 2nd controller. Really. There was a situation with AHCI ports on some systems where an unpopulated port wasn't even advertised as an available channel per AHCI. mav@ believes (as do I) this generally violates AHCI spec, but this is the sort of thing vendors do. Entire post contains the details (including quoted parts): http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029374.html Fixes for that were committed some time ago: head in November 2011 (r227635) and subsequently MFC'd in January 2012 (r229289). > This is not the only problem. Take all the disks out, put them all > back in, do they all have the same names? Unlikely, since their name > is now derived from the controller and port they are plugged in to. > Any changes, and the device name changes. By "name" I assume you mean "device name", e.g. ada0. If so, then the answer is a huge big gigantic fat YES. That is the *entire point* to the wire-down method, and what people have historically complained about (re: solving the issue of adaX or daX devices, or scbusX buses, being reordered/renumbered). If by "take all your disks out and put them all back in" you mean put them all back in to *different physical ports* (i.e. they are now attached to different physical SATA ports) than they were before, then yes, the device name will change (e.g. from ada0 to ada4, assuming you have 1:1 "wire down" mapping like the above). My advice here is the same advice as another user: label what physical SATA port on your system/chassis correlates with what. For systems with hot-swap bays/enclosures, most come with stickers that label each enclosure (starting at either 0 or 1 -- intelligent vendors give you stickers starting at 0). I have yet to encounter a system administrator who thinks a hard disk port should just be treated in an arbitrary "who cares, it's just a port" way. There's always a first. :-) > Using GPT labels is easy to do, and provides a cast iron guarantee > that your disk will not EVER be mistaken for a different drive. Using GPT labels is fine by me, as it's the only one that doesn't have atrocious side effects. But let me introduce you to a fellow who can't use GPT at all, due to his vendor making incorrect assumptions about GPT being UEFI-only, so he's stuck with MBR: http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072188.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072206.html I feel sorry if this guy ever has to deal with a 4096-byte sector disk ("Yeah, so, you get to create your first slice manually, with an offset of a wild/crazy value, because PC architecture is awesome" -- thankfully Warren Block wrote a wonderful page explaining how to do that too). Now back to labels, which I've lectured about in past posts: The labelling situation on FreeBSD is a nightmare given documentation that is unclear or confusing. Examples include gpart(8)'s "add -l" flag, which mentions supporting "labels attached a partition" except never tells you which partition types support labels, and glabel(8) which still to this day cannot figure out if is just an abstraction layer for things like "tunefs -L" (for UFS/UFS2), or if it quite literally has its own "GEOM label" -- the man page implies both. This drives a lot of people away from the whole mechanism. While I appreciate all the very, very hard work pjd@ has put into GEOM and the underlying bits, this situation has existed for a long time. (Yes, go right ahead and tell me "you have the source to the man pages, fix it yourself + file a PR"). And don't get me started on the GPT vs. gmirror/gstripe/graid3 and last-LBA chicken-and-egg problem. > I put a GPT label on the drive, and then write it in permanent marker > on the top of the drive and on a sticky label that is stuck on the > front of the chassis. The disk label never changes in its lifetime, so > you only get issues if you insert a drive without labelling it first. And with CAM(4) wire-down, you could do the exact same except instead of sticking it on the drive, you stick it next to the bay or port, or even on the SATA cable, to say "ada0", "ada1", etc.. Both the wire-down method and your GPT label preference still require one to manually keep track, somehow, of what something physical (whether it be a disk or a port) maps to digitally. Which circles back to what the OP said at the bottom of his thread: "So what gives? Why can't we have something like /dev/hdsn/ (hdsn == Hard Drive Serial Number) where a set of device numbers would automagically ......." ...which I explain the caveats of quite clearly in one of the URLs which you snipped from my mail, specifically the discussion with Warren Block. Those posts: http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071900.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071901.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071904.html The proposed serial/WWN idea sounds great on paper, but in reality create annoying edge-cases that can't be solved. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 25 19:39:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D704024D for ; Mon, 25 Feb 2013 19:39:08 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4867D1A1 for ; Mon, 25 Feb 2013 19:39:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r1PJbYKC028437; Mon, 25 Feb 2013 23:37:34 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 25 Feb 2013 23:37:34 +0400 (MSK) From: Dmitry Morozovsky To: Jeremy Chadwick Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD In-Reply-To: <20130225184745.GA36717@icarus.home.lan> Message-ID: References: <20130124174039.GA35811@icarus.home.lan> <20130225184745.GA36717@icarus.home.lan> 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.2.7 (woozle.rinet.ru [0.0.0.0]); Mon, 25 Feb 2013 23:37:34 +0400 (MSK) Cc: Tom Evans , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 19:39:08 -0000 On Mon, 25 Feb 2013, Jeremy Chadwick wrote: [snip] > For systems with hot-swap bays/enclosures, most come with stickers that label > each enclosure (starting at either 0 or 1 -- intelligent vendors give you > stickers starting at 0). Sidenote: Really intelligent vendors provide you with stickers starting with 0 and ending with, say, 12 for 12-bay chassis, so you can use either numbering scheme as required by driver authors ;-) -- 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 Mon Feb 25 20:17:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11D68D15 for ; Mon, 25 Feb 2013 20:17:55 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id E4BAA38C for ; Mon, 25 Feb 2013 20:17:54 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 4eWH1l00D0x6nqcA1kHufH; Mon, 25 Feb 2013 20:17:54 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id 4kHt1l0031t3BNj8YkHtAN; Mon, 25 Feb 2013 20:17:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 009CB73A1C; Mon, 25 Feb 2013 12:17:52 -0800 (PST) Date: Mon, 25 Feb 2013 12:17:52 -0800 From: Jeremy Chadwick To: Ian Lepore Subject: Re: svn - but smaller? Message-ID: <20130225201752.GA38298@icarus.home.lan> References: <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> <1361749413.16937.16.camel@revolution.hippie.lan> <20130225000454.GA17342@icarus.home.lan> <1361807679.16937.61.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1361807679.16937.61.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361823474; bh=bOrC9shJ76W0CDgvO6VJiciOYS64R0yFihZGnQRFy+E=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=Tcw88qnoBseW0rNzQ3h07pdTxu6+YBz2Fqzl9Z4BHLK4/Sb5BJGc6gZGFZao9cJJa WWvC8B22TGqfT0Mzw92mpbqdgxLkA8vBHm9E9tnpJYtzDA4aQSjSaqUsWdwtzf9ptx HtWhB3PJq9mO/2lhT7hZS98Pyf6aaDbOSAeFqPruUTlpYinVEBwdadIzzQO4/Wvsi2 z2w3ZI6YaHkqjpg6T1lI6pIrvjtb+OnF7bG+z5QIdy+FACEIdVKcp4hi7NbfzF8Jce qWN9GOYo/4qGfjiarqOmfB4hZ9U8F4rqF99g0PLh++qzIInq/cCMEf7RndhPUpeD5c 465wm3hUBCgzw== Cc: Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 25 Feb 2013 20:17:55 -0000 On Mon, Feb 25, 2013 at 08:54:39AM -0700, Ian Lepore wrote: > On Sun, 2013-02-24 at 16:04 -0800, Jeremy Chadwick wrote: > > On Sun, Feb 24, 2013 at 04:43:33PM -0700, Ian Lepore wrote: > > > On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: > > > > On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: > > > > > On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: > > > > > > > > > > > > Also, John, please consider using malloc(3) instead of heap-allocated > > > > > > buffers like file_buffer[6][] (196608 bytes) and command[] (32769 > > > > > > bytes). I'm referring to this: > > > > > > > > > > Why? I absolutely do not understand why people are always objecting to > > > > > large stack-allocated arrays in userland code (sometimes with the > > > > > definition of "large" being as small as 2k for some folks). > > > > > > > > This is incredibly off-topic, but I'll bite. > > > > > > > > I should not have said "heap-allocated", I was actually referring to > > > > statically-allocated. > > > > > > > > The issues as I see them: > > > > > > > > 1. Such buffers exist during the entire program's lifetime even if they > > > > aren't actively used/needed by the program. With malloc(3) and friends, > > > > you're allocating memory dynamically, and you can free(3) when done with > > > > it, rather than just having a gigantic portion of memory allocated > > > > sitting around potentially doing nothing. > > > > > > > > 2. If the length of the buffer exceeds the amount of stack space > > > > available at the time, the program will run but the behaviour is unknown > > > > (I know that on FreeBSD if it exceeds "stacksize" per resource limits, > > > > the program segfaults at runtime). With malloc and friends you can > > > > gracefully handle allocation failures. > > > > > > > > 3. Statically-allocated buffers can't grow; meaning what you've > > > > requested size-wise is all you get. Compare this to something that's > > > > dynamic -- think a linked list containing pointers to malloc'd memory, > > > > which can even be realloc(3)'d if needed. > > > > > > > > The definition of what's "too large" is up to the individual and the > > > > limits of the underlying application. For some people, sure, anything > > > > larger than 2048 might warrant use of malloc. I tend to use malloc for > > > > anything larger than 4096. That "magic number" comes from some piece of > > > > information I was told long ago about what size pages malloc internally > > > > uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it > > > > appears to be a lot more complex than that. > > > > > > > > If you want me to break down #1 for you with some real-world output and > > > > a very small C program, showing you the effects on RES/RSS and SIZE/VIRT > > > > of static vs. dynamic allocation, just ask. > > > > > > > > > > Actually, after seeing that the userland limit for an unpriveleged user > > > on freebsd is a mere 64k, I'd say the only valid reason to not allocate > > > big things on the stack is because freebsd has completely broken > > > defaults. > > > > The limits (i.e. what's shown via limits(1)) differs per architecture > > (ex. i386 vs. amd64) and may adjust based on amount of physical memory > > available (not sure on the latter part). The "64k" value you're talking > > about, I think, is "memorylocked" -- I'm referring to "stacksize". > > > > > I see no reason why there should even be a distinction > > > between stack size and memory use limits in general. Pages are pages, > > > it really doesn't matter what part of your virtual address space they > > > live in. > > > > You're thinking purely of SIZE/VIRT. > > > > I guess I'd best break the C program out. Apologise in advance for the > > crappy code (system(3)!), but I wanted something that made the task > > easy. > > > > $ limits -a > > Resource limits (current): > > cputime infinity secs > > filesize infinity kB > > datasize 2621440 kB > > stacksize 262144 kB > > coredumpsize infinity kB > > memoryuse infinity kB > > memorylocked 64 kB > > maxprocesses 5547 > > openfiles 11095 > > sbsize infinity bytes > > vmemoryuse infinity kB > > pseudo-terminals infinity > > swapuse infinity kB > > > > $ cat x.c > > #include > > #include > > #include > > #include > > #include > > > > #define SIZE_MFATTY 512*1024*1024 /* 512MB */ > > #define SIZE_SFATTY 128*1024*1024 /* 128MB; must be smaller than limits stacksize! */ > > > > int main(int argc, char *argv[]) { > > char procstat[BUFSIZ]; > > char topgrep[BUFSIZ]; > > pid_t mypid; > > char *mfatty; > > char sfatty[SIZE_SFATTY]; > > > > sfatty[0] = '\0'; /* squelch gcc unused var warning */ > > > > mypid = getpid(); > > > > snprintf(procstat, sizeof(procstat), > > "procstat -v %u", mypid); > > snprintf(topgrep, sizeof(topgrep), > > "top -b 99999 | egrep '^(Mem:|[ ]+PID|[ ]*%u)'", mypid); > > > > printf("at startup\n"); > > printf("============\n"); > > system(topgrep); > > printf("-----\n"); > > system(procstat); > > sleep(5); > > > > mfatty = malloc(SIZE_MFATTY); > > printf("\n"); > > printf("after malloc mfatty\n"); > > printf("=====================\n"); > > system(topgrep); > > printf("-----\n"); > > system(procstat); > > sleep(5); > > > > memset(mfatty, 0x0, SIZE_MFATTY); > > memset(&sfatty, 0x0, SIZE_SFATTY); > > printf("\n"); > > printf("after memset mfatty and sfatty\n"); > > printf(" (e.g. pages are marked used/written to)\n"); > > printf("===========================================\n"); > > system(topgrep); > > printf("-----\n"); > > system(procstat); > > sleep(5); > > > > free(mfatty); > > printf("\n"); > > printf("after free mfatty\n"); > > printf("===================\n"); > > system(topgrep); > > printf("-----\n"); > > system(procstat); > > > > return(0); > > } > > > > $ gcc -Wall -o x x.c > > $ ./x > > at startup > > ============ > > Mem: 97M Active, 221M Inact, 1530M Wired, 825M Buf, 6045M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 17567 jdc 1 27 0 138M 1524K wait 1 0:00 0.00% ./x > > ----- > > PID START END PRT RES PRES REF SHD FL TP PATH > > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > > 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 > > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > > 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 > > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 2 0 1 0 C--D df > > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 3 0 1 0 CN-- df > > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph > > > > after malloc mfatty > > ===================== > > Mem: 97M Active, 221M Inact, 1530M Wired, 825M Buf, 6045M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 17567 jdc 1 25 0 650M 1524K wait 3 0:00 0.00% ./x > > ----- > > PID START END PRT RES PRES REF SHD FL TP PATH > > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > > 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 > > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > > 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 > > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > > 17567 0xa1000000 0xc1000000 rw- 0 0 1 0 CN-- df > > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 2 0 1 0 C--D df > > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 3 0 1 0 CN-- df > > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph > > > > after memset mfatty and sfatty > > (e.g. pages are marked used/written to) > > =========================================== > > Mem: 737M Active, 221M Inact, 1531M Wired, 825M Buf, 5404M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 17567 jdc 1 31 0 650M 643M wait 2 0:01 5.27% ./x > > ----- > > PID START END PRT RES PRES REF SHD FL TP PATH > > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > > 17567 0xa0600000 0xa0618000 r-x 24 0 33 0 CN-- vn /libexec/ld-elf.so.1 > > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > > 17567 0xa081a000 0xa094b000 r-x 283 0 57 24 CN-- vn /lib/libc.so.7 > > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > > 17567 0xa1000000 0xc1000000 rw- 131072 0 1 0 CNS- df > > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 32739 0 1 0 C-SD df > > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 32 0 1 0 CN-- df > > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 36 0 CN-- ph > > > > after free mfatty > > =================== > > Mem: 229M Active, 222M Inact, 1531M Wired, 825M Buf, 5913M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 17567 jdc 1 27 0 138M 130M wait 3 0:01 2.78% ./x > > ----- > > PID START END PRT RES PRES REF SHD FL TP PATH > > 17567 0x400000 0x401000 r-x 1 0 1 0 CN-- vn /home/jdc/x > > 17567 0x600000 0x800000 rw- 2 0 1 0 CN-- df > > 17567 0xa0600000 0xa0618000 r-x 24 0 38 0 CN-- vn /libexec/ld-elf.so.1 > > 17567 0xa0618000 0xa0639000 rw- 21 0 1 0 CN-- df > > 17567 0xa0818000 0xa081a000 rw- 2 0 1 0 CN-- df > > 17567 0xa081a000 0xa094b000 r-x 283 0 65 27 CN-- vn /lib/libc.so.7 > > 17567 0xa094b000 0xa0b4a000 --- 0 0 1 0 CN-- df > > 17567 0xa0b4a000 0xa0b55000 rw- 11 0 1 0 CN-- vn /lib/libc.so.7 > > 17567 0xa0b55000 0xa0b6f000 rw- 6 0 1 0 CN-- df > > 17567 0xa0c00000 0xa1000000 rw- 9 0 1 0 CN-- df > > 17567 0x7ffff7fdf000 0x7ffffffdf000 rw- 32739 0 1 0 C-SD df > > 17567 0x7ffffffdf000 0x7ffffffff000 rw- 32 0 1 0 CN-- df > > 17567 0x7ffffffff000 0x800000000000 r-x 0 0 41 0 CN-- ph > > > > Look very carefully at the RES column for that process, particularly > > after the memset(), and then again after the free(). > > > > You'll see quite clearly that the sfatty[] array remains in use, wasting > > memory that could otherwise be used by other processes on the system, up > > until exit. This is also quite apparent in the procstat output. > > > > Moral of the story: it matters (and malloc is your friend). :-) > > > > > Almost everything I've ever done with freebsd runs as root on an > > > embedded system, so I'm not used to thinking in terms of limits at all. > > > > I would think an embedded platform would do the exact opposite -- force > > you to think in terms of limits *all the time*. > > > > For example: I partake in the TomatoUSB project (a Linux-based firmware > > that runs mainly on MIPSR1/R2 boxes); my overall thought process. when > > developing or fixing something relating to TomatoUSB are significantly > > more strict than on a FreeBSD amd64 system with 8GB RAM and an 8-core CPU. > > > > But generally speaking I tend to write code/develop things with > > "minimal" in mind at all times, and that all stems from growing up doing > > assembly on 65xxx systems (Apple II series, Nintendo/Famicom and the > > Super Nintendo/Super Famicom) and PIC -- where CPU time and memory is > > highly limits. I always design things assuming it'll be used on very > > minimal architectures. > > > > I am in no way saying John (or you!) should have the same mentality > > (like I said it varies on environment and application goal and so on), > > but with regards to what I do, KISS principle combined with "minimalist" > > approach has yet to fail me. But there are certainly cases with complex > > applications where you can't design something within those limits (e.g. > > "okay, to do this efficiently, we're going to need to have about > > 128MBytes of non-swapped RAM available just for this process at all > > times"), and I respect that. But my point is that static allocation > > vs. malloc matters more than you think. > > > > So your point is that if a program is going to call deep down into some > chain that uses big stack-allocated buffers, then it continues to run > for some non-trivial amount of time after that, never again descending > that particular call chain, then the memory would have been recovered by > the system faster if it had been malloc'd and free'd rather than stack > allocated. No, that isn't what my point is. I used large numbers to make it more obvious (plus to deal with the KB->MB rounding situation in top). My point is that once the pages of the statically-allocated buffer (sfatty, the 128MByte buffer) are used, they appear to be unreleased until the program exits. Look closely at RES/RSS in the above output. > But if the program uses the big buffers for most of its duration, then > there's no real difference in behavior at all. That's borderline political -- the statement doesn't take into consideration what happens when stacksize is exceeded. Did you see Stephen Montgomery-Smith's reply with mentioning mkctm in the base system? That's a real-world example of this happening, where someone in the past said "screw it" and really didn't think about the bigger picture (other platforms, memory limitations, etc.). > If the big buffers are smaller than the limit within the malloc > implementation that triggers a MADV_DONTNEED immediately, (for example, > if they were less than... I think it's 4MB in our current > implementation) then there's no real difference. I'm guessing you had > to use such extreme sized buffers to demonstrate your point because with > something more reasonable (we were talking about ~200K of IO buffers > originally) there was no difference. I changed the declared sizes of mfatty and sfatty to 8MBytes and 2MBytes respectively -- I wanted sfatty under this 4MByte number you're talking about. I threw a sleep(300) (5 minutes) followed by a couple more system()s to see if pagedaemon (or whatever piece of the kernel VM) reaped or even swapped out the memory associated with sfatty. It didn't: startup: 38827 jdc 1 26 0 11976K 1392K wait 3 0:00 0.00% ./x malloc: 38827 jdc 1 25 0 20168K 1392K wait 0 0:00 0.00% ./x memset: 38827 jdc 1 23 0 20168K 11640K wait 2 0:00 0.00% ./x free: 38827 jdc 1 22 0 11976K 3432K wait 0 0:00 0.00% ./x sleep300: 38827 jdc 1 20 0 11976K 3432K wait 2 0:00 0.00% ./x The procstat output for the relevant pages (sfatty) also did not change (meaning the TP field did not change, nor did FL). You can clearly see the 2MBytes "laying around". As I understand it, this is because free(), via libc, can tell the kernel immediately the kernel "I'm done with this", while such isn't the case for something allocated during executable load-time. Again, as I understand it, such can only be released when the program exits. > I guess the moral of the story is don't use huge stack-allocated buffers > once at startup in a daemon, especially if megabytes are involved. But > if you're writing some normal program that needs some memory for a while > for its major tasks, and when its done with those tasks it exits, > then... there's no real difference. Sure, this matters significantly more for daemons than programs which do exit regularly, but that's splitting hairs. Think about multiple instances of a program, or a multi-user machine (e.g. shell boxes), or a program that simply runs for a while, or said program being used on a system with smaller resources than you yourself are used to. There was a thread somewhat recently on one of the lists, I forget which/where, where people were talking about using present-day FreeBSD on systems with either 64MB or 128MB of RAM (something "really small" by today's standards). You might think 32768*6 wouldn't matter to them, but what if their box is a squid proxy, where most of the RAM is for content cache? Suddenly it matters more. When I write software, I try to think minimally. I grew up developing on the original Apple II series (64KB RAM barring the IIGS) and later the 286/386, along with some PICs, and the thought process that went along with the architectural/system limitations has stuck with me since. I don't get exceedingly pedantic unless the software plans on being used on a very minimal architecture (I've done a lot of development on the NES/Famicom which has only 2KB RAM, for example). If I don't know what architecture it'll be used on, I try to be reasonable without being overly pedantic (e.g. worrying about every single last bit); ex. worrying about what fits into L1/L2 cache lines and so on is something I generally tend to leave to the compiler on present-day platforms (it matters though, even in our malloc(3) implementation!). > Which I guess means the real bottom-line moral of the story is that > there are no simple mantras. "Don't use big stack allocated buffers" is > going to be wrong as many times as "Always allocate everything on the > stack" -- you can come up with examples that refute each assertion. Absolutely (with regards to your last point), and I don't want to make it sound like I'm just going to pull arguments out of my ass solely for the sake of arguing. As with everything in programming there are many variables involved in software design; there are absolutely cases where a statically-allocated buffer has its merits. Example off the top of my head: a program where CPU time matters and a tight loop is involved (the overhead of calling malloc/free repeatedly chewing up too much time, where using a statically-allocated buffer relieves that pain). Trade-off is worth it. So logically the next question would be "so where do you draw the line?" And my answer would be this: "if you're unsure where to draw the line, or unaware of the benefits and drawbacks of statically-allocated buffers, or don't know when they're applicable, use malloc/free". *shrug* That's just how I operate. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 05:43:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A16AE0C for ; Tue, 26 Feb 2013 05:43:38 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntqsrv03p.mx.bigpond.com (nskntqsrv03p.mx.bigpond.com [61.9.168.237]) by mx1.freebsd.org (Postfix) with ESMTP id 80469E36 for ; Tue, 26 Feb 2013 05:43:36 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20130226043120.PVKX29723.nskntmtas03p.mx.bigpond.com@nskntcmgw08p>; Tue, 26 Feb 2013 04:31:20 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nskntcmgw08p with BigPond Outbound id 4sXK1l0045LKYmq01sXKlA; Tue, 26 Feb 2013 04:31:20 +0000 X-Authority-Analysis: v=2.0 cv=FNuZNpUs c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=FUvQB3dvW0AA:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=6vs_tXDfI7oA:10 a=8nLEPu7vQWd-c2whEpUA:9 a=CjuIK1q_8ugA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r1Q4TgAE051932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 15:29:42 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Jeremy Chadwick'" References: <20130124174039.GA35811@icarus.home.lan> <20130225184745.GA36717@icarus.home.lan> Subject: RE: RFC: Suggesting ZFS "best practices" in FreeBSD Date: Tue, 26 Feb 2013 15:29:41 +1100 Message-ID: <7D95AB554F564375A886F7F48BDC96CC@white> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20130225184745.GA36717@icarus.home.lan> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4TiLMBSqBBmG+SQFyvlTWXM3cPwQATlqjQ Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 05:43:38 -0000 Jeremy, Thank-you very much for an enlightening explanation that has changed my current disk naming/labelling approach. glabel continues to have its place with usb memory sticks. I'd glanced at cam(4) but didn't absorb the beneficial significance. Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 06:10:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82880828 for ; Tue, 26 Feb 2013 06:10:45 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4A996EF4 for ; Tue, 26 Feb 2013 06:10:45 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=YKIdOG6x c=1 sm=0 a=sCkZyOwU0IjLO1BAXY68/A==:17 a=d8Isu0L9vBEA:10 a=ifD4dwJ5zREA:10 a=YNqtyO0l_hcA:10 a=LaogzpLLAAAA:8 a=JQ6KEy0en_sA:10 a=fSSSqy-nXpwx6qCE8ywA:9 a=wPNLvfGTeEIA:10 a=6I5d2MoRAAAA:8 a=iy7kP6ay90DODtPXsa8A:9 a=_W_S_7VecoQA:10 a=SV7veod9ZcQA:10 a=lTq853n_a1GgR9Fj:21 a=sCkZyOwU0IjLO1BAXY68/A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 173.63.211.146 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [173.63.211.146] ([173.63.211.146:37819] helo=[192.168.1.8]) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTPA id 4F/46-28101-ED15C215; Tue, 26 Feb 2013 01:10:38 -0500 Message-ID: <512C51DD.4090506@aldan.algebra.com> Date: Tue, 26 Feb 2013 01:10:37 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130209 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: FreeBSD-9.1 would not boot on pentium3 laptop References: <5111DE44.7040008@aldan.algebra.com> <5113F24E.3070207@aldan.algebra.com> <201302071425.17064.jhb@freebsd.org> <201302150849.29085.jhb@freebsd.org> In-Reply-To: <201302150849.29085.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 06:10:45 -0000 15.02.2013 08:49, John Baldwin ???????(??): > Were you able to test this patch? Yes, with the patch my laptop boots -- even after I removed the work-around (hint.ichss.0.disabled="1" from device.hints). powerd is also able to regulate the frequency -- I'm not sure, how else to test the functionality. Thank you. Yours, -mi > >> > Index: ichss.c >> > =================================================================== >> > --- ichss.c (revision 246122) >> > +++ ichss.c (working copy) >> > @@ -67,7 +67,7 @@ struct ichss_softc { >> > #define PCI_DEV_82801BA 0x244c /* ICH2M */ >> > #define PCI_DEV_82801CA 0x248c /* ICH3M */ >> > #define PCI_DEV_82801DB 0x24cc /* ICH4M */ >> > -#define PCI_DEV_82815BA 0x1130 /* Unsupported/buggy part */ >> > +#define PCI_DEV_82815_MC 0x1130 /* Unsupported/buggy part */ ... From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 07:34:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 921BD92C for ; Tue, 26 Feb 2013 07:34:04 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id EB4B7242 for ; Tue, 26 Feb 2013 07:34:03 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r1Q7Xwpt031611 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 26 Feb 2013 09:33:59 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <512C6566.9040400@digsys.bg> Date: Tue, 26 Feb 2013 09:33:58 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.12) Gecko/20130125 Thunderbird/10.0.12 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD References: <20130124174039.GA35811@icarus.home.lan> <512B94EB.30201@denninger.net> In-Reply-To: <512B94EB.30201@denninger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 07:34:04 -0000 On 25.02.13 18:44, Karl Denninger wrote: > On 2/25/2013 8:31 AM, Tom Evans wrote: >> Using GPT labels is easy to do, and provides a cast iron guarantee >> that your disk will not EVER be mistaken for a different drive. >> >> I put a GPT label on the drive, and then write it in permanent marker >> on the top of the drive and on a sticky label that is stuck on the >> front of the chassis. The disk label never changes in its lifetime, so >> you only get issues if you insert a drive without labelling it first. >> >> Cheers >> >> Tom >> > Listen to this man. Either do it in gpart or do it with glabel > (depending on where you want it to show up); once done the drive will > always have the same name in the device tree no matter what slot it > shows up in. > > Then stick that label on the front of the drive carrier, and you never > have this problem. > > Do that or suffer. Your choice. > I can only second this advice. Learn to make your setups as generic as possible. Wiring down device names using CAM etc, only complicates matters, at least because that knowledge is contained within the system you boot, not the drive. If you boot from an "recovery media", all of your "fine crafted" CAM wire-down system will be gone and you will suffer. You will suffer exactly at the moment when you need those labels most. Not wise. Yes, Jeremy, there is always the first time. Both glabel and GPT labels do the trick. Both behave differently and depending on your habits and intended usage one or the other is good. Just don't be inclined to use both at the same time. My personal preference as of later is GPT labels. By the way, "glabel" is a generic term in FreeBSD. It refers to all label types, including those created with glabel, gpart and newfs/tunefs. The later are not really "geom labels", these are volume labels, but glabel is smart enough to detect/report them, even if it can't manipulate these labels. I don't find the glabel documentation all that confusing. Daniel From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 09:11:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3877F17F for ; Tue, 26 Feb 2013 09:11:24 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id B4BA57A2 for ; Tue, 26 Feb 2013 09:11:23 +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.69) (envelope-from ) id 1UAGZ8-0006fr-1O for freebsd-stable@freebsd.org; Tue, 26 Feb 2013 10:11:15 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAGZ8-0004l9-1G for freebsd-stable@freebsd.org; Tue, 26 Feb 2013 10:11:14 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD References: <20130124174039.GA35811@icarus.home.lan> <512B94EB.30201@denninger.net> <512C6566.9040400@digsys.bg> Date: Tue, 26 Feb 2013 10:11:14 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <512C6566.9040400@digsys.bg> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 9b84bad32751a42de3aa9e7877f1ca86 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 09:11:24 -0000 On Tue, 26 Feb 2013 08:33:58 +0100, Daniel Kalchev wrote: > > > On 25.02.13 18:44, Karl Denninger wrote: >> On 2/25/2013 8:31 AM, Tom Evans wrote: >>> Using GPT labels is easy to do, and provides a cast iron guarantee >>> that your disk will not EVER be mistaken for a different drive. >>> >>> I put a GPT label on the drive, and then write it in permanent marker >>> on the top of the drive and on a sticky label that is stuck on the >>> front of the chassis. The disk label never changes in its lifetime, so >>> you only get issues if you insert a drive without labelling it first. >>> >>> Cheers >>> >>> Tom >>> >> Listen to this man. Either do it in gpart or do it with glabel >> (depending on where you want it to show up); once done the drive will >> always have the same name in the device tree no matter what slot it >> shows up in. >> >> Then stick that label on the front of the drive carrier, and you never >> have this problem. >> >> Do that or suffer. Your choice. >> > > I can only second this advice. > > Learn to make your setups as generic as possible. Wiring down device > names using CAM etc, only complicates matters, at least because that > knowledge is contained within the system you boot, not the drive. If you > boot from an "recovery media", all of your "fine crafted" CAM wire-down > system will be gone and you will suffer. You will suffer exactly at the > moment when you need those labels most. Not wise. > Yes, Jeremy, there is always the first time. > > Both glabel and GPT labels do the trick. Both behave differently and > depending on your habits and intended usage one or the other is good. > Just don't be inclined to use both at the same time. My personal > preference as of later is GPT labels. > > By the way, "glabel" is a generic term in FreeBSD. It refers to all > label types, including those created with glabel, gpart and > newfs/tunefs. The later are not really "geom labels", these are volume > labels, but glabel is smart enough to detect/report them, even if it > can't manipulate these labels. I don't find the glabel documentation all > that confusing. > > Daniel I second that. Ronald From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 12:47:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3AEFDE9; Tue, 26 Feb 2013 12:47:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 915827D; Tue, 26 Feb 2013 12:47:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D62A7B976; Tue, 26 Feb 2013 07:47:14 -0500 (EST) From: John Baldwin To: Glen Barber Subject: Re: IPMI serial console Date: Mon, 25 Feb 2013 16:32:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <00CC60B5-A6EB-4A3C-B8AC-1D60014DE442@gsoft.com.au> <201302211723.14730.jhb@freebsd.org> <20130221225501.GR1491@glenbarber.us> In-Reply-To: <20130221225501.GR1491@glenbarber.us> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302251632.15594.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 07:47:14 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 12:47:15 -0000 On Thursday, February 21, 2013 5:55:01 pm Glen Barber wrote: > On Thu, Feb 21, 2013 at 05:23:14PM -0500, John Baldwin wrote: > > On Thursday, February 21, 2013 4:56:02 pm Daniel O'Connor wrote: > > > > > > On 22/02/2013, at 2:19, John Baldwin wrote: > > > >> Does anyone have any hints? > > > > > > > > Rather than using all these hints, just use these three in loader.conf: > > > > > > > > console="comconsole vidconsole" > > > > console_speed=115200 > > > > console_port="0x" (where is the correct I/O port for COM3, > > 0x3e8 > > > > maybe?) > > > > > > > > > No dice :( > > > > > > I also tried booting with '-D -h -S 115200' but nothing either. > > > > Sorry, those should be 'comconsole_speed' and 'comconsole_port'. Also, you > > should be able to get the loader prompt working if you enter those by hand > > using an IPMI KVM or some such. > > > > John, this sounds very similar to a question I posed to you a few weeks > ago. I guess it's not "just me" with these weird SuperMicro BMCs. :( I am using exactly this on many SuperMicro X8 and X9 boards. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 12:47:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4EF1CEE1 for ; Tue, 26 Feb 2013 12:47:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE257F for ; Tue, 26 Feb 2013 12:47:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68767B9A4; Tue, 26 Feb 2013 07:47:16 -0500 (EST) From: John Baldwin To: "Daniel O'Connor" Subject: Re: IPMI serial console Date: Mon, 25 Feb 2013 16:34:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <00CC60B5-A6EB-4A3C-B8AC-1D60014DE442@gsoft.com.au> <201302211723.14730.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302251634.13110.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 07:47:16 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 12:47:17 -0000 On Thursday, February 21, 2013 5:42:08 pm Daniel O'Connor wrote: > > On 22/02/2013, at 8:53, John Baldwin wrote: > >> I also tried booting with '-D -h -S 115200' but nothing either. > > > > Sorry, those should be 'comconsole_speed' and 'comconsole_port'. Also, you > > should be able to get the loader prompt working if you enter those by hand > > using an IPMI KVM or some such. > > > No luck with that either :( > > The IPMI serial console works for the BIOS & loader so I guess the comconsole parts work, however the kernel doesn't seem to use it even with '-D -h'. > > The uart(4) flags are correct (I believe) > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 5 flags 0x30 on acpi0 The way this works with the kernel is that the loader has to be setting a hw.uart.console hint based on comconsole_port. The hint.uart.X.flags settings are completely ignored for this. Also, for 9.1, you must set the speed before you set the port (so the order of lines in loader.conf matters), or hw.uart.console will tell the kernel to use 9600 instead of 115200. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 18:31:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A9CA0956 for ; Tue, 26 Feb 2013 18:31:54 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from smtp19.mail.ru (smtp19.mail.ru [94.100.176.156]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4D61688 for ; Tue, 26 Feb 2013 18:31:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Type:Subject:CC:To:MIME-Version:Reply-To:From:Date:Message-ID; bh=q4LYIAfsnTmsSG2dh8xtQ361ZNKNva+2qDYUeKZQmRk=; b=xiztacM0CTDlU8gWWyMPf4BVCv7GOaQleghWWuaFbg5zszhWe2Fvy6otlEW6UfalGGcv0DSJvrK91aq6z/PFfAJbFwwf2L/EoV8pmr0dbGrJ5fYaxg67oN1nrZoYTUnq; Received: from [217.25.27.27] (port=15167) by smtp19.mail.ru with esmtpa (envelope-from ) id 1UAPJa-0008H3-Is; Tue, 26 Feb 2013 22:31:46 +0400 Message-ID: <512CFF90.8080806@mail.ru> Date: Tue, 26 Feb 2013 22:31:44 +0400 From: rihad User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: mfi timeouts X-Spam: Not detected X-Mras: Ok Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "rihad@mail.ru >> rihad" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:31:54 -0000 > On 28/10/2011 04:14, Jan Mikkelsen wrote: > >/ Hi, > />/ > />/ There is a patch linked to from this PR, which seems very similar: > />/ > />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 > />/ > />/ http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html > />/ > />/ The problem is also consistent with running mfiutil clearing the problem. > />/ > />/ I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the problem for you. > />/ > /This looks promising, I'll give a try when I get a moment. Hi, Did the patch help? We're having the same issues & running "mfiutil show volumes" every minute doesn't make the freezes go away. Will this small patch be ok on 8.2-RELEASE-p4? Thanks. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 18:32:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31943A64 for ; Tue, 26 Feb 2013 18:32:36 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8426C16BF for ; Tue, 26 Feb 2013 18:32:35 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r1QIWWiY049368 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 00:32:32 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <512CFFBF.3080108@norma.perm.ru> Date: Wed, 27 Feb 2013 00:32:31 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: watchdogs References: <512525C1.1070502@norma.perm.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Wed, 27 Feb 2013 00:32:33 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 18:32:36 -0000 Hi. On 22.02.2013 22:47, Mark Atkinson wrote: > I just want to /metoo that I have 32bit/i386 box running zfs, pf and > - -current that is hardlocking randomly (usually has an uptime for a few > days to a couple weeks). SW_WATCHDOG won't fire when it locks so it > must be locking pretty fast. > > I just noticed that ichwd will load on this box, so I'll try that > instead, but now I'm wondering if the SW_WATCHDOG kernel will > interfere or rather if watchdogd is smart enough to handle both? > > This box used to occasionally panic on the ZFS stack panic so I did > the KSTACK_PAGES=4 change to the kernel and now it just hardlocks. > I'm not saying they are related. > > I also have an 32-bit box running zfs/pf, and it's pretty stable (though I'm knoking on wood right now :) ): [emz@witchdoctor:~]> uptime 23:25 up 291 days, 15:44, 1 user, load averages: 0,04 0,04 0,00 but it's running 8.2-STABLE: 8.2-STABLE FreeBSD 8.2-STABLE #0: Tue Sep 20 19:24:35 YEKST 2011 I've also stopped using zfs swap, I'm still not sure whether this added some stability or not, but still. To be honest it's running without any swap last 291 days. :P This machine has only 2 gigs of ram. It's a file storage, dozens of users use it. I've seen some zfs panicks, I've added options KVA_PAGES=512, and it's working like that. So maybe you should try this. I should also say that it's pf is simple and basic (a couple of pass/block rules, nothing complicated). Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 18:35:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7119EE9 for ; Tue, 26 Feb 2013 18:35:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A6DF71717 for ; Tue, 26 Feb 2013 18:35:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0BE30B976; Tue, 26 Feb 2013 13:35:56 -0500 (EST) From: John Baldwin To: "Mikhail T." Subject: Re: FreeBSD-9.1 would not boot on pentium3 laptop Date: Tue, 26 Feb 2013 13:35:52 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5111DE44.7040008@aldan.algebra.com> <201302150849.29085.jhb@freebsd.org> <512C51DD.4090506@aldan.algebra.com> In-Reply-To: <512C51DD.4090506@aldan.algebra.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302261335.52163.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 13:35:56 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 18:35:56 -0000 On Tuesday, February 26, 2013 1:10:37 am Mikhail T. wrote: > 15.02.2013 08:49, John Baldwin ???????(??): > > Were you able to test this patch? > Yes, with the patch my laptop boots -- even after I removed the > work-around (hint.ichss.0.disabled="1" from device.hints). powerd is > also able to regulate the frequency -- I'm not sure, how else to test > the functionality. > > Thank you. Yours, Perfect, thanks for testing! -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 21:27:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8B58F94 for ; Tue, 26 Feb 2013 21:27:28 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 73CAE18F for ; Tue, 26 Feb 2013 21:27:28 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.6/8.14.6) with ESMTP id r1QLRQbi061654 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 21:27:26 GMT (envelope-from vince@unsane.co.uk) Message-ID: <512D28BB.4080402@unsane.co.uk> Date: Tue, 26 Feb 2013 21:27:23 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "rihad@mail.ru >> rihad" Subject: Re: mfi timeouts References: <512CFF90.8080806@mail.ru> In-Reply-To: <512CFF90.8080806@mail.ru> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 21:27:28 -0000 On 26/02/2013 18:31, rihad wrote: >> On 28/10/2011 04:14, Jan Mikkelsen wrote: >> >/ Hi, >> />/ >> />/ There is a patch linked to from this PR, which seems very similar: >> />/ >> />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 >> />/ >> />/ http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html >> />/ >> />/ The problem is also consistent with running mfiutil clearing the problem. >> />/ >> />/ I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the problem for you. >> />/ >> /This looks promising, I'll give a try when I get a moment. > > Hi, > > Did the patch help? We're having the same issues & running "mfiutil > show volumes" every minute doesn't make the freezes go away. > Will this small patch be ok on 8.2-RELEASE-p4? Thanks. >From what I remember this patch did help. That server has been running happily on 8.3 release for the last 300 days or so with no timeouts. Vince From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 22:09:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28C7AFF8 for ; Tue, 26 Feb 2013 22:09:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0566A347 for ; Tue, 26 Feb 2013 22:09:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5C8F8B95E; Tue, 26 Feb 2013 17:09:33 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org, "rihad@mail.ru >> rihad" Subject: Re: mfi timeouts Date: Tue, 26 Feb 2013 15:48:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512CFF90.8080806@mail.ru> In-Reply-To: <512CFF90.8080806@mail.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302261548.56253.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 17:09:33 -0500 (EST) Cc: vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 22:09:34 -0000 On Tuesday, February 26, 2013 1:31:44 pm rihad wrote: > > On 28/10/2011 04:14, Jan Mikkelsen wrote: > > >/ Hi, > > />/ > > />/ There is a patch linked to from this PR, which seems very similar: > > />/ > > />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 > > />/ > > />/ http://lists.freebsd.org/pipermail/freebsd-scsi/2011- March/004839.html > > />/ > > />/ The problem is also consistent with running mfiutil clearing the problem. > > />/ > > />/ I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the problem for you. > > />/ > > /This looks promising, I'll give a try when I get a moment. > > Hi, > > Did the patch help? We're having the same issues & running "mfiutil show > volumes" every minute doesn't make the freezes go away. > Will this small patch be ok on 8.2-RELEASE-p4? Thanks. You can use the patch on 8.2. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 23:02:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB3A2D15 for ; Tue, 26 Feb 2013 23:02:48 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id CC53B7F8 for ; Tue, 26 Feb 2013 23:02:48 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 51vG1l0031smiN4A3B2otw; Tue, 26 Feb 2013 23:02:48 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id 5B2n1l00X1t3BNj8gB2nHr; Tue, 26 Feb 2013 23:02:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6D14773A1C; Tue, 26 Feb 2013 15:02:47 -0800 (PST) Date: Tue, 26 Feb 2013 15:02:47 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Subject: Outdated pci_vendors Message-ID: <20130226230247.GA67777@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361919768; bh=PYqXZSYeUUhmyEkxLwb07ZRlUhGRni4QqtHOdwyBpgU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=md74nnvUD1GN4hdImbFVg3Jbcx7amzVPCtalrFSsFRxDjOoznXLtCNniGt3r0f+Fd vzgSzzyEU3BI5ibOYF/QOMvdW/idpzPtQ2gWp3Io1HEaosQ/WyDIbSTD2k/zf44XZ+ bKWZukp7V/DuSNuRLzp4hxvGYn2tAgiw+g1A1eBj1QoC0Nz+LLgIgmFsh0X1VdMBx5 flCtkYZNRDwq2uyNyXGioICXUXe/30ztTcc3zbufKSVQxXYTmw1aRz/IqWAz7YiIFj Ifl+lu2Prv09Xd2Bbs4wB1koUwSipJvJNN2SQmeqiJOq4lZtshP4LBH5emGWLfs1yW HLbc6CugtN9yQ== Cc: philip@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 23:02:49 -0000 (CC'ing philip@ since he used to be my commit mentor and is the one who did the most recent head import) Is there anyone in particular who maintains src/share/misc/pci_vendors ? The file[1] on stable/9 is over a year old, and there are some mistakes in it which have since been addressed (this was indirectly brought to my attention on a recent -stable thread involving ICH7 chipsets). It also looks like the MFC'ing of r242471 (circa November 2012) never happened[2]. I would suggest getting the latest set[3] and adding that to head, then MFC'ing that (but do we really need to wait 2 weeks? I can do a full test of it on stable/9 if need be). If all this needs is a PR + patch, just say that and I'll go do it. :-) [1]: http://svnweb.freebsd.org/base/stable/9/share/misc/pci_vendors [2]: http://svnweb.freebsd.org/base/head/share/misc/pci_vendors#rev242471 [3]: http://pciids.sourceforge.net/v2.2/pci.ids -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 23:06:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 67B56E56 for ; Tue, 26 Feb 2013 23:06:52 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.paeps.cx (rincewind.paeps.cx [89.106.240.149]) by mx1.freebsd.org (Postfix) with ESMTP id 1995582E for ; Tue, 26 Feb 2013 23:06:51 +0000 (UTC) Received: from twoflower.paeps.cx (94-224-97-116.access.telenet.be [94.224.97.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip) by rincewind.paeps.cx (Postfix) with ESMTPSA id 1CF3ED74400; Wed, 27 Feb 2013 00:06:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Outdated pci_vendors From: Philip Paeps In-Reply-To: <20130226230247.GA67777@icarus.home.lan> Date: Wed, 27 Feb 2013 00:06:55 +0100 Content-Transfer-Encoding: 7bit Message-Id: <542C373C-FB16-4746-A7E8-271BB4B42A77@freebsd.org> References: <20130226230247.GA67777@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 23:06:52 -0000 On 27 Feb 2013, at 00:02, Jeremy Chadwick wrote: > (CC'ing philip@ since he used to be my commit mentor and is the one who > did the most recent head import) > > Is there anyone in particular who maintains src/share/misc/pci_vendors ? I've been taking care of it for a bit. > The file[1] on stable/9 is over a year old, and there are some mistakes > in it which have since been addressed (this was indirectly brought to my > attention on a recent -stable thread involving ICH7 chipsets). > > It also looks like the MFC'ing of r242471 (circa November 2012) never > happened[2]. Oh, whoops. Looks like I forgot the MFC. I have been very distracted. > I would suggest getting the latest set[3] and adding that to head, then > MFC'ing that (but do we really need to wait 2 weeks? I can do a full > test of it on stable/9 if need be). > > If all this needs is a PR + patch, just say that and I'll go do it. :-) I'll take care of it. Thanks for the reminder! - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 23:20:18 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 069E0540; Tue, 26 Feb 2013 23:20:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 979A68C4; Tue, 26 Feb 2013 23:20:17 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r1QNKG5u033465; Tue, 26 Feb 2013 23:20:16 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r1QNKGGT033420; Tue, 26 Feb 2013 23:20:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Feb 2013 23:20:16 GMT Message-Id: <201302262320.r1QNKGGT033420@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 23:20:18 -0000 TB --- 2013-02-26 21:23:55 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-02-26 21:23:55 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-02-26 21:23:55 - starting RELENG_9 tinderbox run for arm/arm TB --- 2013-02-26 21:23:55 - cleaning the object tree TB --- 2013-02-26 21:23:55 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-02-26 21:23:55 - cd /tinderbox/RELENG_9/arm/arm TB --- 2013-02-26 21:23:55 - /usr/local/bin/svn cleanup /src TB --- 2013-02-26 21:24:58 - /usr/local/bin/svn update /src TB --- 2013-02-26 21:25:12 - building world TB --- 2013-02-26 21:25:12 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 21:25:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 21:25:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 21:25:12 - SRCCONF=/dev/null TB --- 2013-02-26 21:25:12 - TARGET=arm TB --- 2013-02-26 21:25:12 - TARGET_ARCH=arm TB --- 2013-02-26 21:25:12 - TZ=UTC TB --- 2013-02-26 21:25:12 - __MAKE_CONF=/dev/null TB --- 2013-02-26 21:25:12 - cd /src TB --- 2013-02-26 21:25:12 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 26 21:25:13 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Feb 26 22:36:41 UTC 2013 TB --- 2013-02-26 22:36:42 - cd /src/sys/arm/conf TB --- 2013-02-26 22:36:42 - /usr/sbin/config -m AVILA TB --- 2013-02-26 22:36:42 - building AVILA kernel TB --- 2013-02-26 22:36:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:36:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:36:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:36:42 - SRCCONF=/dev/null TB --- 2013-02-26 22:36:42 - TARGET=arm TB --- 2013-02-26 22:36:42 - TARGET_ARCH=arm TB --- 2013-02-26 22:36:42 - TZ=UTC TB --- 2013-02-26 22:36:42 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:36:42 - cd /src TB --- 2013-02-26 22:36:42 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue Feb 26 22:36:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Tue Feb 26 22:41:00 UTC 2013 TB --- 2013-02-26 22:41:00 - cd /src/sys/arm/conf TB --- 2013-02-26 22:41:00 - /usr/sbin/config -m BWCT TB --- 2013-02-26 22:41:00 - building BWCT kernel TB --- 2013-02-26 22:41:00 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:41:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:41:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:41:00 - SRCCONF=/dev/null TB --- 2013-02-26 22:41:00 - TARGET=arm TB --- 2013-02-26 22:41:00 - TARGET_ARCH=arm TB --- 2013-02-26 22:41:00 - TZ=UTC TB --- 2013-02-26 22:41:00 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:41:00 - cd /src TB --- 2013-02-26 22:41:00 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Feb 26 22:41:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Tue Feb 26 22:43:51 UTC 2013 TB --- 2013-02-26 22:43:51 - cd /src/sys/arm/conf TB --- 2013-02-26 22:43:51 - /usr/sbin/config -m CAMBRIA TB --- 2013-02-26 22:43:51 - building CAMBRIA kernel TB --- 2013-02-26 22:43:51 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:43:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:43:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:43:51 - SRCCONF=/dev/null TB --- 2013-02-26 22:43:51 - TARGET=arm TB --- 2013-02-26 22:43:51 - TARGET_ARCH=arm TB --- 2013-02-26 22:43:51 - TZ=UTC TB --- 2013-02-26 22:43:51 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:43:51 - cd /src TB --- 2013-02-26 22:43:51 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Tue Feb 26 22:43:51 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Tue Feb 26 22:47:13 UTC 2013 TB --- 2013-02-26 22:47:13 - cd /src/sys/arm/conf TB --- 2013-02-26 22:47:13 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-02-26 22:47:13 - building CNS11XXNAS kernel TB --- 2013-02-26 22:47:13 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:47:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:47:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:47:13 - SRCCONF=/dev/null TB --- 2013-02-26 22:47:13 - TARGET=arm TB --- 2013-02-26 22:47:13 - TARGET_ARCH=arm TB --- 2013-02-26 22:47:13 - TZ=UTC TB --- 2013-02-26 22:47:13 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:47:13 - cd /src TB --- 2013-02-26 22:47:13 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Tue Feb 26 22:47:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Tue Feb 26 22:50:17 UTC 2013 TB --- 2013-02-26 22:50:17 - cd /src/sys/arm/conf TB --- 2013-02-26 22:50:17 - /usr/sbin/config -m CRB TB --- 2013-02-26 22:50:17 - building CRB kernel TB --- 2013-02-26 22:50:17 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:50:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:50:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:50:17 - SRCCONF=/dev/null TB --- 2013-02-26 22:50:17 - TARGET=arm TB --- 2013-02-26 22:50:17 - TARGET_ARCH=arm TB --- 2013-02-26 22:50:17 - TZ=UTC TB --- 2013-02-26 22:50:17 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:50:17 - cd /src TB --- 2013-02-26 22:50:17 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Tue Feb 26 22:50:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Tue Feb 26 22:54:27 UTC 2013 TB --- 2013-02-26 22:54:27 - cd /src/sys/arm/conf TB --- 2013-02-26 22:54:27 - /usr/sbin/config -m DB-78XXX TB --- 2013-02-26 22:54:27 - building DB-78XXX kernel TB --- 2013-02-26 22:54:27 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:54:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:54:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:54:27 - SRCCONF=/dev/null TB --- 2013-02-26 22:54:27 - TARGET=arm TB --- 2013-02-26 22:54:27 - TARGET_ARCH=arm TB --- 2013-02-26 22:54:27 - TZ=UTC TB --- 2013-02-26 22:54:27 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:54:27 - cd /src TB --- 2013-02-26 22:54:27 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Tue Feb 26 22:54:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Tue Feb 26 22:57:35 UTC 2013 TB --- 2013-02-26 22:57:35 - cd /src/sys/arm/conf TB --- 2013-02-26 22:57:35 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-02-26 22:57:35 - building DB-88F5XXX kernel TB --- 2013-02-26 22:57:35 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:57:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:57:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:57:35 - SRCCONF=/dev/null TB --- 2013-02-26 22:57:35 - TARGET=arm TB --- 2013-02-26 22:57:35 - TARGET_ARCH=arm TB --- 2013-02-26 22:57:35 - TZ=UTC TB --- 2013-02-26 22:57:35 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:57:35 - cd /src TB --- 2013-02-26 22:57:35 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Tue Feb 26 22:57:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Tue Feb 26 23:00:49 UTC 2013 TB --- 2013-02-26 23:00:49 - cd /src/sys/arm/conf TB --- 2013-02-26 23:00:49 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-02-26 23:00:49 - building DB-88F6XXX kernel TB --- 2013-02-26 23:00:49 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:00:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:00:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:00:49 - SRCCONF=/dev/null TB --- 2013-02-26 23:00:49 - TARGET=arm TB --- 2013-02-26 23:00:49 - TARGET_ARCH=arm TB --- 2013-02-26 23:00:49 - TZ=UTC TB --- 2013-02-26 23:00:49 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:00:49 - cd /src TB --- 2013-02-26 23:00:49 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Tue Feb 26 23:00:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Tue Feb 26 23:04:01 UTC 2013 TB --- 2013-02-26 23:04:01 - cd /src/sys/arm/conf TB --- 2013-02-26 23:04:01 - /usr/sbin/config -m DOCKSTAR TB --- 2013-02-26 23:04:01 - building DOCKSTAR kernel TB --- 2013-02-26 23:04:01 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:04:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:04:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:04:01 - SRCCONF=/dev/null TB --- 2013-02-26 23:04:01 - TARGET=arm TB --- 2013-02-26 23:04:01 - TARGET_ARCH=arm TB --- 2013-02-26 23:04:01 - TZ=UTC TB --- 2013-02-26 23:04:01 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:04:01 - cd /src TB --- 2013-02-26 23:04:01 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Tue Feb 26 23:04:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Tue Feb 26 23:07:27 UTC 2013 TB --- 2013-02-26 23:07:27 - cd /src/sys/arm/conf TB --- 2013-02-26 23:07:27 - /usr/sbin/config -m EP80219 TB --- 2013-02-26 23:07:27 - building EP80219 kernel TB --- 2013-02-26 23:07:27 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:07:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:07:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:07:27 - SRCCONF=/dev/null TB --- 2013-02-26 23:07:27 - TARGET=arm TB --- 2013-02-26 23:07:27 - TARGET_ARCH=arm TB --- 2013-02-26 23:07:27 - TZ=UTC TB --- 2013-02-26 23:07:27 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:07:27 - cd /src TB --- 2013-02-26 23:07:27 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Tue Feb 26 23:07:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Tue Feb 26 23:11:10 UTC 2013 TB --- 2013-02-26 23:11:10 - cd /src/sys/arm/conf TB --- 2013-02-26 23:11:10 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-02-26 23:11:10 - building ETHERNUT5 kernel TB --- 2013-02-26 23:11:10 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:11:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:11:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:11:10 - SRCCONF=/dev/null TB --- 2013-02-26 23:11:10 - TARGET=arm TB --- 2013-02-26 23:11:10 - TARGET_ARCH=arm TB --- 2013-02-26 23:11:10 - TZ=UTC TB --- 2013-02-26 23:11:10 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:11:10 - cd /src TB --- 2013-02-26 23:11:10 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Tue Feb 26 23:11:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> mxge (all) ===> mxge/mxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c cc1: warnings being treated as errors /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c: In function 'mxge_intr': /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:3105: warning: large integer implicitly truncated to unsigned type [-Woverflow] /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c: In function 'mxge_attach': /src/sys/modules/mxge/mxge/../../../dev/mxge/if_mxge.c:4897: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/mxge/mxge. *** Error code 1 Stop in /src/sys/modules/mxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-26 23:20:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-26 23:20:16 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-02-26 23:20:16 - 4746.88 user 816.72 system 6981.29 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 26 23:39:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D1ED1B02 for ; Tue, 26 Feb 2013 23:39:35 +0000 (UTC) (envelope-from prvs=17696a5c94=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 57C9196A for ; Tue, 26 Feb 2013 23:39:35 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002420518.msg for ; Tue, 26 Feb 2013 23:39:27 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 26 Feb 2013 23:39:27 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17696a5c94=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: , References: <512CFF90.8080806@mail.ru> Subject: Re: mfi timeouts Date: Tue, 26 Feb 2013 23:39:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Feb 2013 23:39:35 -0000 ----- Original Message ----- From: "rihad" >> On 28/10/2011 04:14, Jan Mikkelsen wrote: >> >/ Hi, >> />/ >> />/ There is a patch linked to from this PR, which seems very similar: >> />/ >> />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 >> />/ >> />/ http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html >> />/ >> />/ The problem is also consistent with running mfiutil clearing the problem. >> />/ >> />/ I'm about to deploy mfi controllers in a similar configuration, so I'd be very curious about whether the patch fixes the >> problem for you. >> />/ >> /This looks promising, I'll give a try when I get a moment. > > Hi, > > Did the patch help? We're having the same issues & running "mfiutil show volumes" every minute doesn't make the freezes go away. > Will this small patch be ok on 8.2-RELEASE-p4? Thanks. I'm about to commit a major patch to mfi, which many problems with the current driver. Given info in that PR it could well fix this problem. Unfortunately due to the number of changes, its likely to sit in head for a while before it gets MFC, just to be safe. We've been running it on 8.3-RELEASE on top of the driver from head for some months and not issues so far. So if anyone is interested in a patchset for that I'll be able to provide. I'll post a link to the commit when I'm done. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 02:10:04 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98A72825; Wed, 27 Feb 2013 02:10:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 59214191; Wed, 27 Feb 2013 02:10:04 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r1R2A38V049578; Wed, 27 Feb 2013 02:10:03 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r1R2A3ha049577; Wed, 27 Feb 2013 02:10:03 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Feb 2013 02:10:03 GMT Message-Id: <201302270210.r1R2A3ha049577@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 02:10:04 -0000 TB --- 2013-02-26 22:56:48 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-02-26 22:56:48 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-02-26 22:56:48 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-02-26 22:56:48 - cleaning the object tree TB --- 2013-02-26 22:56:48 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-02-26 22:56:48 - cd /tinderbox/RELENG_9/i386/i386 TB --- 2013-02-26 22:56:48 - /usr/local/bin/svn cleanup /src TB --- 2013-02-26 22:58:02 - /usr/local/bin/svn update /src TB --- 2013-02-26 22:58:16 - building world TB --- 2013-02-26 22:58:16 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 22:58:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 22:58:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 22:58:16 - SRCCONF=/dev/null TB --- 2013-02-26 22:58:16 - TARGET=i386 TB --- 2013-02-26 22:58:16 - TARGET_ARCH=i386 TB --- 2013-02-26 22:58:16 - TZ=UTC TB --- 2013-02-26 22:58:16 - __MAKE_CONF=/dev/null TB --- 2013-02-26 22:58:16 - cd /src TB --- 2013-02-26 22:58:16 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 26 22:58:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 27 01:58:13 UTC 2013 TB --- 2013-02-27 01:58:13 - generating LINT kernel config TB --- 2013-02-27 01:58:13 - cd /src/sys/i386/conf TB --- 2013-02-27 01:58:13 - /usr/bin/make -B LINT TB --- 2013-02-27 01:58:13 - cd /src/sys/i386/conf TB --- 2013-02-27 01:58:13 - /usr/sbin/config -m LINT TB --- 2013-02-27 01:58:13 - building LINT kernel TB --- 2013-02-27 01:58:13 - CROSS_BUILD_TESTING=YES TB --- 2013-02-27 01:58:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-27 01:58:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-27 01:58:13 - SRCCONF=/dev/null TB --- 2013-02-27 01:58:13 - TARGET=i386 TB --- 2013-02-27 01:58:13 - TARGET_ARCH=i386 TB --- 2013-02-27 01:58:13 - TZ=UTC TB --- 2013-02-27 01:58:13 - __MAKE_CONF=/dev/null TB --- 2013-02-27 01:58:13 - cd /src TB --- 2013-02-27 01:58:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 27 01:58:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] uudecode -o mwlboot.fw /src/sys/contrib/dev/mwl/mwlboot.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o mwlboot.fwo mwlboot.fw cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/mxge/if_mxge.c cc1: warnings being treated as errors /src/sys/dev/mxge/if_mxge.c: In function 'mxge_intr': /src/sys/dev/mxge/if_mxge.c:3105: warning: large integer implicitly truncated to unsigned type [-Woverflow] /src/sys/dev/mxge/if_mxge.c: In function 'mxge_attach': /src/sys/dev/mxge/if_mxge.c:4897: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-27 02:10:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-27 02:10:03 - ERROR: failed to build LINT kernel TB --- 2013-02-27 02:10:03 - 8407.99 user 939.84 system 11595.64 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 02:12:33 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6FE5CA1A; Wed, 27 Feb 2013 02:12:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 36A031C9; Wed, 27 Feb 2013 02:12:33 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r1R2CWPO057365; Wed, 27 Feb 2013 02:12:32 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r1R2CWJR057364; Wed, 27 Feb 2013 02:12:32 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Feb 2013 02:12:32 GMT Message-Id: <201302270212.r1R2CWJR057364@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 02:12:33 -0000 TB --- 2013-02-26 23:01:23 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-02-26 23:01:23 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-02-26 23:01:23 - starting RELENG_9 tinderbox run for i386/pc98 TB --- 2013-02-26 23:01:23 - cleaning the object tree TB --- 2013-02-26 23:01:23 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-02-26 23:01:23 - cd /tinderbox/RELENG_9/i386/pc98 TB --- 2013-02-26 23:01:23 - /usr/local/bin/svn cleanup /src TB --- 2013-02-26 23:02:38 - /usr/local/bin/svn update /src TB --- 2013-02-26 23:02:48 - building world TB --- 2013-02-26 23:02:48 - CROSS_BUILD_TESTING=YES TB --- 2013-02-26 23:02:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-26 23:02:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-26 23:02:48 - SRCCONF=/dev/null TB --- 2013-02-26 23:02:48 - TARGET=pc98 TB --- 2013-02-26 23:02:48 - TARGET_ARCH=i386 TB --- 2013-02-26 23:02:48 - TZ=UTC TB --- 2013-02-26 23:02:48 - __MAKE_CONF=/dev/null TB --- 2013-02-26 23:02:48 - cd /src TB --- 2013-02-26 23:02:48 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 26 23:02:49 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 27 02:02:03 UTC 2013 TB --- 2013-02-27 02:02:03 - generating LINT kernel config TB --- 2013-02-27 02:02:03 - cd /src/sys/pc98/conf TB --- 2013-02-27 02:02:03 - /usr/bin/make -B LINT TB --- 2013-02-27 02:02:03 - cd /src/sys/pc98/conf TB --- 2013-02-27 02:02:03 - /usr/sbin/config -m LINT TB --- 2013-02-27 02:02:04 - building LINT kernel TB --- 2013-02-27 02:02:04 - CROSS_BUILD_TESTING=YES TB --- 2013-02-27 02:02:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-27 02:02:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-27 02:02:04 - SRCCONF=/dev/null TB --- 2013-02-27 02:02:04 - TARGET=pc98 TB --- 2013-02-27 02:02:04 - TARGET_ARCH=i386 TB --- 2013-02-27 02:02:04 - TZ=UTC TB --- 2013-02-27 02:02:04 - __MAKE_CONF=/dev/null TB --- 2013-02-27 02:02:04 - cd /src TB --- 2013-02-27 02:02:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 27 02:02:04 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/mwl/if_mwl_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/mwl/mwlhal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/mxge/if_mxge.c cc1: warnings being treated as errors /src/sys/dev/mxge/if_mxge.c: In function 'mxge_intr': /src/sys/dev/mxge/if_mxge.c:3105: warning: large integer implicitly truncated to unsigned type [-Woverflow] /src/sys/dev/mxge/if_mxge.c: In function 'mxge_attach': /src/sys/dev/mxge/if_mxge.c:4897: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-27 02:12:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-27 02:12:32 - ERROR: failed to build LINT kernel TB --- 2013-02-27 02:12:32 - 8266.07 user 953.71 system 11468.94 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 05:58:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0561E18; Wed, 27 Feb 2013 05:58:21 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) by mx1.freebsd.org (Postfix) with ESMTP id 4FAE7AD9; Wed, 27 Feb 2013 05:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=vdnJoZAX6UdNjJ+HeRDne+ymwfpVDnW8SaNwGJZt+vQ=; b=qB8o1ZaOuhk6Q19KN2D2ONj3iUAe8BT9tWqsKsT9X1fo3TC8D+O+lxIHsvMPVBWsnrxHJPhq00KksYQAzZdMhnRWp9UWtsc+bsWRBiribkNnrhtBqfWc4BcdmqvjTYOT; Received: from [217.25.27.27] (port=21180) by smtp50.i.mail.ru with esmtpa (envelope-from ) id 1UAa1t-0006C7-PN; Wed, 27 Feb 2013 09:58:14 +0400 Message-ID: <512DA073.9090908@mail.ru> Date: Wed, 27 Feb 2013 09:58:11 +0400 From: rihad User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: mfi timeouts References: <512CFF90.8080806@mail.ru> <201302261548.56253.jhb@freebsd.org> In-Reply-To: <201302261548.56253.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 05:58:21 -0000 On 02/27/2013 12:48 AM, John Baldwin wrote: > On Tuesday, February 26, 2013 1:31:44 pm rihad wrote: >>> On 28/10/2011 04:14, Jan Mikkelsen wrote: >>>> / Hi, >>> />/ >>> />/ There is a patch linked to from this PR, which seems very similar: >>> />/ >>> />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 >>> />/ >>> />/ http://lists.freebsd.org/pipermail/freebsd-scsi/2011- > March/004839.html >>> />/ >>> />/ The problem is also consistent with running mfiutil clearing the > problem. >>> />/ >>> />/ I'm about to deploy mfi controllers in a similar configuration, so > I'd be very curious about whether the patch fixes the problem for you. >>> />/ >>> /This looks promising, I'll give a try when I get a moment. >> Hi, >> >> Did the patch help? We're having the same issues & running "mfiutil show >> volumes" every minute doesn't make the freezes go away. >> Will this small patch be ok on 8.2-RELEASE-p4? Thanks. > You can use the patch on 8.2. > Thanks, I was forced to apply the patch to 8.2-p4 and rebuild the kernel yesterday in the night, as it sometimes locks up both interfaces in periods of high disk/net activity (around 4-5 gbit/s passing through). Has anyone had full system lock-ups besides the i/o stall & mfi timeout errors? I hope those issues are related. In such cases sometimes one of the interfaces lives, sometimes both are down. Happened 2-3 times during a little over a month. Now about this part taken from here http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html > By issuing a dummy read operation (thus forcing a flush of data buffers), this issue is largely averted. Does this mean that battery-backed cache (BBU) is effectively rendered useless, as all write operations are forced on to the disk platters on every interrupt? # mfiutil show adapter mfi0 Adapter: Product Name: Integrated Intel(R) RAID Controller SROMBSASMP2 Serial Number: Firmware: 8.0.1-0033 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8K Maximum Stripe: 1M From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 06:05:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7CD1FE7 for ; Wed, 27 Feb 2013 06:05:58 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from smtp19.mail.ru (smtp19.mail.ru [94.100.176.156]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF8AB2B for ; Wed, 27 Feb 2013 06:05:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UBx3tEsYjs9F0CtRxDa4Vc69/NHB76Vz8DN/VmC3REY=; b=AgMhwFLnZ5SZiZXjkmkvgD60dHjsy4n5IJdpUX165GGhdH15MJCZj0BngecZ4nUw4K0LkiBVxVbGOm4+rZ57Jf1CVeQTojfBr+Gf3pNntrLEOJTqmpM1t+ui+dV8QsUg; Received: from [217.25.27.27] (port=35980) by smtp19.mail.ru with esmtpa (envelope-from ) id 1UAa9M-0001ti-GT; Wed, 27 Feb 2013 10:05:56 +0400 Message-ID: <512DA242.4060903@mail.ru> Date: Wed, 27 Feb 2013 10:05:54 +0400 From: rihad User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Steven Hartland Subject: Re: mfi timeouts References: <512CFF90.8080806@mail.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 06:05:58 -0000 On 02/27/2013 03:39 AM, Steven Hartland wrote: > ----- Original Message ----- From: "rihad" > > >>> On 28/10/2011 04:14, Jan Mikkelsen wrote: >>> >/ Hi, >>> />/ >>> />/ There is a patch linked to from this PR, which seems very similar: >>> />/ >>> />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 >>> />/ >>> />/ >>> http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html >>> />/ >>> />/ The problem is also consistent with running mfiutil clearing >>> the problem. >>> />/ >>> />/ I'm about to deploy mfi controllers in a similar configuration, >>> so I'd be very curious about whether the patch fixes the problem for >>> you. >>> />/ >>> /This looks promising, I'll give a try when I get a moment. >> >> Hi, >> >> Did the patch help? We're having the same issues & running "mfiutil >> show volumes" every minute doesn't make the freezes go away. >> Will this small patch be ok on 8.2-RELEASE-p4? Thanks. > > I'm about to commit a major patch to mfi, which many problems with the > current driver. Given info in that PR it could well fix this problem. > > Unfortunately due to the number of changes, its likely to sit in head > for a > while before it gets MFC, just to be safe. > > We've been running it on 8.3-RELEASE on top of the driver from head for > some months and not issues so far. So if anyone is interested in a > patchset for that I'll be able to provide. > > I'll post a link to the commit when I'm done. Thanks, if the trivial dummy read proves insufficient, sure I'll need to look into that :) Thanks. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 06:33:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8BF63737; Wed, 27 Feb 2013 06:33:57 +0000 (UTC) (envelope-from sales@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4B8CD9; Wed, 27 Feb 2013 06:33:57 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id C1C081BCD87; Wed, 27 Feb 2013 02:33:49 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 83205-05; Wed, 27 Feb 2013 06:33:49 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id CE9CC1BCD86; Wed, 27 Feb 2013 02:33:48 -0400 (AST) From: Sales Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Odd issue with VirtualBox+9-STABLE+bce ... Date: Tue, 26 Feb 2013 22:33:47 -0800 Message-Id: <2A0FD48D-6CEF-4A70-B915-724315C48674@hub.org> To: "freebsd-net@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "freebsd-emulation@freebsd.org" , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 06:33:57 -0000 I'm experiencing some odd issues with Virtualbox running on 9-STABLE. = where my network periodically disappears =85 sometimes, it comes back = again after a few minutes, other times I have to reboot the server =85 This last time, the error on the screen states: bce1: bce_pulse(): Warning: boot code thinks driver is absent! (bc_state = =3D 0x00004006) I had 20 regular 'jail' VPSs running on it before I tried VirtualBox on = it,and never had this problem, so figure it has to be something with = VirtualBox / kmod =85 ? Anyone experiencing any odd issues with VirtualBox and 9-STABLE? = Pointers / ideas? Thx =85 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 09:31:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD03A353 for ; Wed, 27 Feb 2013 09:31:36 +0000 (UTC) (envelope-from prvs=17707c68ac=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 62F61311 for ; Wed, 27 Feb 2013 09:31:36 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002428079.msg for ; Wed, 27 Feb 2013 09:31:34 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 27 Feb 2013 09:31:34 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17707c68ac=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <42BE7BD6F8A142519256B1AF7DBE13C2@multiplay.co.uk> From: "Steven Hartland" To: "rihad" References: <512CFF90.8080806@mail.ru> <512DA242.4060903@mail.ru> Subject: Re: mfi timeouts Date: Wed, 27 Feb 2013 09:31:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 09:31:36 -0000 ----- Original Message ----- From: "rihad" >>> Did the patch help? We're having the same issues & running "mfiutil >>> show volumes" every minute doesn't make the freezes go away. >>> Will this small patch be ok on 8.2-RELEASE-p4? Thanks. >> >> I'm about to commit a major patch to mfi, which many problems with the >> current driver. Given info in that PR it could well fix this problem. >> >> Unfortunately due to the number of changes, its likely to sit in head >> for a >> while before it gets MFC, just to be safe. >> >> We've been running it on 8.3-RELEASE on top of the driver from head for >> some months and not issues so far. So if anyone is interested in a >> patchset for that I'll be able to provide. >> >> I'll post a link to the commit when I'm done. > > > Thanks, if the trivial dummy read proves insufficient, sure I'll need to > look into that :) Thanks. Ok patch is in; two parts the second as I mentioned its a bit of monster I'm afraid. http://svnweb.freebsd.org/base?view=revision&revision=247367 http://svnweb.freebsd.org/base?view=revision&revision=247369 With the exception of the recent busdma changes: http://svnweb.freebsd.org/base?view=revision&revision=246713 the entire driver back ports trivially to 8 so should be good with 9 too. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 17:12:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C620C9B1 for ; Wed, 27 Feb 2013 17:12:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0362F76 for ; Wed, 27 Feb 2013 17:12:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07F4AB945; Wed, 27 Feb 2013 12:12:49 -0500 (EST) From: John Baldwin To: rihad Subject: Re: mfi timeouts Date: Wed, 27 Feb 2013 11:59:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512CFF90.8080806@mail.ru> <201302261548.56253.jhb@freebsd.org> <512DA073.9090908@mail.ru> In-Reply-To: <512DA073.9090908@mail.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302271159.13424.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 12:12:49 -0500 (EST) Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 17:12:49 -0000 On Wednesday, February 27, 2013 12:58:11 am rihad wrote: > Now about this part taken from here > http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html > > By issuing a dummy read operation (thus forcing a flush of data > buffers), this issue is largely averted. > > Does this mean that battery-backed cache (BBU) is effectively rendered > useless, as all write operations are forced on to the disk platters on > every interrupt? No, this is a very different level. This is forcing pending PCI DMA transactions on the PCI bus to flush by doing a read, not forcing I/O buffers to be flushed to disk. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 21:19:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 323CC905 for ; Wed, 27 Feb 2013 21:19:32 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id E745BFC0 for ; Wed, 27 Feb 2013 21:19:31 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id j6so2261840oag.36 for ; Wed, 27 Feb 2013 13:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Mx9+soe9XYY1IdmPjo/W+RHIM2zXYU1rmKqjm/7whe4=; b=YQvY4fr+usu8l7h2azEgOZTyX0eL8F8RTgNzpjWqrmeul8qzBpIiVQHEMa/aO6ww18 EOJZ4Bob0DZOfvs2i93XZye7wpmrpJkbkxA1AFIaiTEapG6V4AdtA7n9z/uK8p70uoZZ GmBlqf0kbqoP0wWvtP3sDdghWZlpUsvO+CQ8m/J5W/Og0NLI4SwqJqCBlgv8fmJAl7Wq o0OK+lV14WRAP5/d79n+kD81xPPG70qwkwva5TBsHZdLcuGt6Ur8h8WENQp+gtrRRTT2 cG3/B19oA1GTU2/WVr9CID4hYa6n8uYqYDEAW3gPAkStoN6GEb5SVyHAyzwXwwEifl/J 3KWg== MIME-Version: 1.0 X-Received: by 10.60.19.228 with SMTP id i4mr3829983oee.40.1361999971185; Wed, 27 Feb 2013 13:19:31 -0800 (PST) Received: by 10.76.94.12 with HTTP; Wed, 27 Feb 2013 13:19:31 -0800 (PST) Date: Wed, 27 Feb 2013 22:19:31 +0100 Message-ID: Subject: rc.d/sysctl fails to parse sysctl.conf From: Andreas Nilsson To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 21:19:32 -0000 Hello, I tried to get my sound working, and long story short: rc.d/sysctl parses sysctl.conf wrongly if there are sysctls of the form mib=val1=val2 which is what you need for sound. For reference I needed/wanted dev.hdaa.4.nid25_config=as=1,seq=15 dev.hdaa.4.nid31_config=as=1 I believe the following patch would address the incorrect parsing: --- /etc/rc.d/sysctl.old 2013-02-27 22:00:00.000000000 +0100 +++ /etc/rc.d/sysctl 2013-02-27 22:05:24.000000000 +0100 @@ -26,7 +26,7 @@ \#*|'') ;; *) - mib=${var%=*} + mib=${var%%=*} val=${var#*=} if current_value=`${SYSCTL} -n ${mib} 2>/dev/null`; then Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 21:40:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5285FFD9 for ; Wed, 27 Feb 2013 21:40:16 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 20D4C1B5 for ; Wed, 27 Feb 2013 21:40:16 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so1244471ieb.31 for ; Wed, 27 Feb 2013 13:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Xc5nMElVyC6YEe6BMP6Alntzo9fbyroeF1eW0louMuY=; b=mckYBzMfaAjP8j7aX/wTidfbE63H7lrVcSmpjX8VsxDqTD1i+lpucKqQSWmpWQ12qz O2WeATkMkwxP7gRXtvdJl05JrxoDyh+j+O51ECfvTXTTpzr0Gm4TcWE+kqfx9KB6gXj5 EFyM+IbGfT7MsK6xn2Y6qkWv2kd9cszDMgGoKHw+pcimIkYsbsgHawt3WvtjUbyyAwo0 IWtaodC05afJtj4/z4F6yzvLdt8oogJOSSdn2Jr1+7rAgCQ/z3S1xpXa+IwGWph0B/xU Wj+wOfWQfPFZwtYV2gve1mHEAuTpsV5qMrRbiZcrA7twlftz5afq9pgCsLmhMYLvJ1fy EXbw== X-Received: by 10.42.92.72 with SMTP id s8mr1704299icm.0.1362001215866; Wed, 27 Feb 2013 13:40:15 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.63.12 with HTTP; Wed, 27 Feb 2013 13:39:45 -0800 (PST) In-Reply-To: References: From: Chris Rees Date: Wed, 27 Feb 2013 21:39:45 +0000 X-Google-Sender-Auth: oXcQjtqt58xm6fln5SdMrH_E6zU Message-ID: Subject: Re: rc.d/sysctl fails to parse sysctl.conf To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 27 Feb 2013 21:40:16 -0000 On 27 February 2013 21:19, Andreas Nilsson wrote: > Hello, > > I tried to get my sound working, and long story short: rc.d/sysctl parses > sysctl.conf wrongly if there are sysctls of the form > > mib=val1=val2 > > which is what you need for sound. For reference I needed/wanted > > dev.hdaa.4.nid25_config=as=1,seq=15 > dev.hdaa.4.nid31_config=as=1 > > I believe the following patch would address the incorrect parsing: > > --- /etc/rc.d/sysctl.old 2013-02-27 22:00:00.000000000 +0100 > +++ /etc/rc.d/sysctl 2013-02-27 22:05:24.000000000 +0100 > @@ -26,7 +26,7 @@ > \#*|'') > ;; > *) > - mib=${var%=*} > + mib=${var%%=*} > val=${var#*=} > > if current_value=`${SYSCTL} -n ${mib} > 2>/dev/null`; then I think that this is the right thing to do here. Chris From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 01:41:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66C95E1E for ; Thu, 28 Feb 2013 01:41:23 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) by mx1.freebsd.org (Postfix) with ESMTP id 3E7DCCA for ; Thu, 28 Feb 2013 01:41:23 +0000 (UTC) Received: from chombo.houseloki.net (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by rush.bluerosetech.com (Postfix) with ESMTPSA id 13D7A11437 for ; Wed, 27 Feb 2013 17:41:15 -0800 (PST) Received: from [127.0.0.1] (ivo.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id CF2704DE for ; Wed, 27 Feb 2013 17:41:13 -0800 (PST) Message-ID: <512EB5BD.1020803@bluerosetech.com> Date: Wed, 27 Feb 2013 17:41:17 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Building RELENG_9 (or RELENG_9_*) on a small machine? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 01:41:23 -0000 So I have this VM which only has 256 MB of memory and 9.1-R installed. I want to update it to RELENG_9, but buildworld swaps so bad it grinds nearly to a halt. Even make -j1 -B runs into very heavy swapping. So two questions: 1. Is there anything I can do to set a limit on how much memory the compiler uses? 2. If I crossbuild for this machine, can I get away with doing buildworld on a buildbox, ship the obj tree, and do installworld and mergemaster on the VM? It's been a few enternities since I did a cross build and back then it was crossbuilding releases. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 01:46:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFD991D3; Thu, 28 Feb 2013 01:46:40 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id BAF65121; Thu, 28 Feb 2013 01:46:40 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id B053723F645; Wed, 27 Feb 2013 20:46:37 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us B053723F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Feb 2013 20:46:35 -0500 From: Glen Barber To: Darren Pilgrim Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? Message-ID: <20130228014635.GB70215@glenbarber.us> References: <512EB5BD.1020803@bluerosetech.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: <512EB5BD.1020803@bluerosetech.com> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 01:46:41 -0000 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 05:41:17PM -0800, Darren Pilgrim wrote: > So I have this VM which only has 256 MB of memory and 9.1-R installed.=20 > I want to update it to RELENG_9, but buildworld swaps so bad it grinds=20 > nearly to a halt. Even make -j1 -B runs into very heavy swapping. So=20 > two questions: >=20 > 1. Is there anything I can do to set a limit on how much memory the=20 > compiler uses? >=20 You can disable building clang with this line in /etc/src.conf: WITHOUT_CLANG=3Dyes > 2. If I crossbuild for this machine, can I get away with doing=20 > buildworld on a buildbox, ship the obj tree, and do installworld and=20 > mergemaster on the VM? It's been a few enternities since I did a cross= =20 > build and back then it was crossbuilding releases. Yes, that should work. Glen --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRLrb7AAoJEFJPDDeguUaj3C8H/0GNosJftPFyahGAsDpxdRjx QEn9xXUwrCr0s5eVJno3rfch/KHeNMugizMO1jYeEI/Sh29QKoVAzajVNRMNgU7G Ai4g7OQDxtKu4lHkBpx/l+d4TPoHWuY0rF1+Hz/H/h39KcmPSCUzgkDatF47YGjQ +myQb9XWVC3+bD2cmZiPD8HReO+D8IdMUVck6F+xAI50YiGa/mcCFjtxS7BqmMAi NRM54HAt0aRbnrGQtfHczyvyR5TPsAuicRKI53Z8PSJmzxxf7nARgchVQ25WGJHj NPjdYwcL32MRMsFCS0JSo0dGyaLC6/J1q+yKD0yaFiC5hOqj/8U0WI23uk7WtKA= =pD1v -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 02:12:25 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EC4AF4DF; Thu, 28 Feb 2013 02:12:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id AA8671CC; Thu, 28 Feb 2013 02:12:25 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S2COdc072869; Thu, 28 Feb 2013 02:12:24 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S2COim072864; Thu, 28 Feb 2013 02:12:24 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 02:12:24 GMT Message-Id: <201302280212.r1S2COim072864@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:12:26 -0000 TB --- 2013-02-28 01:25:07 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 01:25:07 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 01:25:07 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2013-02-28 01:25:07 - cleaning the object tree TB --- 2013-02-28 01:25:07 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 01:25:07 - cd /tinderbox/RELENG_8/powerpc/powerpc TB --- 2013-02-28 01:25:07 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 01:25:15 - /usr/local/bin/svn update /src TB --- 2013-02-28 01:25:22 - building world TB --- 2013-02-28 01:25:22 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 01:25:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 01:25:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 01:25:22 - SRCCONF=/dev/null TB --- 2013-02-28 01:25:22 - TARGET=powerpc TB --- 2013-02-28 01:25:22 - TARGET_ARCH=powerpc TB --- 2013-02-28 01:25:22 - TZ=UTC TB --- 2013-02-28 01:25:22 - __MAKE_CONF=/dev/null TB --- 2013-02-28 01:25:22 - cd /src TB --- 2013-02-28 01:25:22 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 01:25:22 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 02:09:32 UTC 2013 TB --- 2013-02-28 02:09:32 - generating LINT kernel config TB --- 2013-02-28 02:09:32 - cd /src/sys/powerpc/conf TB --- 2013-02-28 02:09:32 - /usr/bin/make -B LINT TB --- 2013-02-28 02:09:32 - cd /src/sys/powerpc/conf TB --- 2013-02-28 02:09:32 - /usr/sbin/config -m LINT TB --- 2013-02-28 02:09:32 - building LINT kernel TB --- 2013-02-28 02:09:32 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 02:09:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 02:09:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 02:09:32 - SRCCONF=/dev/null TB --- 2013-02-28 02:09:32 - TARGET=powerpc TB --- 2013-02-28 02:09:32 - TARGET_ARCH=powerpc TB --- 2013-02-28 02:09:32 - TZ=UTC TB --- 2013-02-28 02:09:32 - __MAKE_CONF=/dev/null TB --- 2013-02-28 02:09:32 - cd /src TB --- 2013-02-28 02:09:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 02:09:32 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 02:12:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 02:12:24 - ERROR: failed to build LINT kernel TB --- 2013-02-28 02:12:24 - 2405.71 user 414.98 system 2837.04 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 02:16:27 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6AAFB618; Thu, 28 Feb 2013 02:16:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 2747F1F3; Thu, 28 Feb 2013 02:16:27 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S2GQAd004660; Thu, 28 Feb 2013 02:16:26 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S2GQLS004659; Thu, 28 Feb 2013 02:16:26 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 02:16:26 GMT Message-Id: <201302280216.r1S2GQLS004659@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:16:27 -0000 TB --- 2013-02-28 01:31:52 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 01:31:52 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 01:31:52 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2013-02-28 01:31:52 - cleaning the object tree TB --- 2013-02-28 01:31:52 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 01:31:52 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2013-02-28 01:31:52 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 01:31:59 - /usr/local/bin/svn update /src TB --- 2013-02-28 01:32:04 - building world TB --- 2013-02-28 01:32:04 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 01:32:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 01:32:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 01:32:04 - SRCCONF=/dev/null TB --- 2013-02-28 01:32:04 - TARGET=sparc64 TB --- 2013-02-28 01:32:04 - TARGET_ARCH=sparc64 TB --- 2013-02-28 01:32:04 - TZ=UTC TB --- 2013-02-28 01:32:04 - __MAKE_CONF=/dev/null TB --- 2013-02-28 01:32:04 - cd /src TB --- 2013-02-28 01:32:04 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 01:32:04 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 02:13:36 UTC 2013 TB --- 2013-02-28 02:13:36 - generating LINT kernel config TB --- 2013-02-28 02:13:36 - cd /src/sys/sparc64/conf TB --- 2013-02-28 02:13:36 - /usr/bin/make -B LINT TB --- 2013-02-28 02:13:36 - cd /src/sys/sparc64/conf TB --- 2013-02-28 02:13:36 - /usr/sbin/config -m LINT TB --- 2013-02-28 02:13:36 - building LINT kernel TB --- 2013-02-28 02:13:36 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 02:13:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 02:13:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 02:13:36 - SRCCONF=/dev/null TB --- 2013-02-28 02:13:36 - TARGET=sparc64 TB --- 2013-02-28 02:13:36 - TARGET_ARCH=sparc64 TB --- 2013-02-28 02:13:36 - TZ=UTC TB --- 2013-02-28 02:13:36 - __MAKE_CONF=/dev/null TB --- 2013-02-28 02:13:36 - cd /src TB --- 2013-02-28 02:13:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 02:13:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 02:16:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 02:16:26 - ERROR: failed to build LINT kernel TB --- 2013-02-28 02:16:26 - 2273.77 user 402.33 system 2674.48 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 02:23:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E525903; Thu, 28 Feb 2013 02:23:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx1.freebsd.org (Postfix) with ESMTP id E2C1C249; Thu, 28 Feb 2013 02:23:54 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id 16so1019488wgi.3 for ; Wed, 27 Feb 2013 18:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3sCu9MyNVBOBf6Um6bRpLiZJ4wrJegTssPu7u2EN/xk=; b=un8pm2mQz5+QeeF3hZKMkDlXUXwt0gq/hVHHAQCdW9Q1ARylj4qXJDLM8qynyTkrT5 HQGwuV9tTi7w4iaZ/RwVAVUkin05cOsz0G+tkbk9jo/61CWdtzUMIXbJObiM4p6cEXDG 0gXAIyQ/54X7V9nOa62P9HhSe9ewjsQtaca2PD2be3E5ONS04esKrSyP5cJSgsTbZl+4 axaM75XAmP1eMNkQvYL4HEDwnqyo46sVBTZ4VZgcvLD4TENrwtNzb4irz9V1diUaMvSZ TXxTIgL5kMCn5c9u8OmGjlaSXZs5S1sD0+rhPULaZdj4ObbvFKKzlvWdyVAFy12Oh12Q XcgQ== MIME-Version: 1.0 X-Received: by 10.180.108.229 with SMTP id hn5mr2564500wib.28.1362018228341; Wed, 27 Feb 2013 18:23:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 18:23:48 -0800 (PST) In-Reply-To: <20130228014635.GB70215@glenbarber.us> References: <512EB5BD.1020803@bluerosetech.com> <20130228014635.GB70215@glenbarber.us> Date: Wed, 27 Feb 2013 18:23:48 -0800 X-Google-Sender-Auth: dJnKuElqpv7D9IE3DOtadza8FYE Message-ID: Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Darren Pilgrim X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 02:23:55 -0000 Hm, have you disabled that CAM target layer stuff at boot? It's likely tying up some RAM. Adrian From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 02:26:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B9AAEA54; Thu, 28 Feb 2013 02:26:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 37D7C263; Thu, 28 Feb 2013 02:26:29 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id x8so1104948wey.34 for ; Wed, 27 Feb 2013 18:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=d/6soJ4dnNeuk/6K2S1XIlzY8pwAr5daE3jY8qWfz9o=; b=N2lPiS7lTssu9bX93j0fiVVbwMD+lO1XmHjaivLux3hFi/CVYW2LStFFX5IrS/o5kv iKs0oLmZTfnx/z2aUBR5VSMoFlSuSI/T6NhrLNpr3+18DvJ5/iknogKcsL7wkAYL6ZS8 ++Pod+vuSrgdYv4OQXScOmUT0MrEYx/xD1KG2whg9klWge25jON6BJTDzrdZv5/tFlbY OfMnCs61uQtybWXhINj3oUIIUpA6SXiRnQIKMCWQ7exk3WINlj8QMCY01bBqlZ6dO2h3 IRxkICECU4NyyVK0qujj465V5d2vg+J8ZrdLUoy/uoks+CuQKejYG1iEnMGbSfneBi4Z mJAg== MIME-Version: 1.0 X-Received: by 10.194.110.69 with SMTP id hy5mr7921580wjb.1.1362018388366; Wed, 27 Feb 2013 18:26:28 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 18:26:28 -0800 (PST) In-Reply-To: References: <1356218834151-5771583.post@n5.nabble.com> <50D644E5.9070801@martenvijn.nl> Date: Wed, 27 Feb 2013 18:26:28 -0800 X-Google-Sender-Auth: JfGHpJ8mbJCexaeaLHB1PmBHe_Y Message-ID: Subject: Re: 9.1 minimal ram requirements From: Adrian Chadd To: Sergey Kandaurov , ken@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Marten Vijn , freebsd-stable@freebsd.org, jakub_lach@mailplus.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 02:26:29 -0000 Hi Ken, I'd like to fix this for 9.2 and -HEAD. Would you mind if I disabled CTL in GENERIC (but still build it as a module) until you've fixed the initial RAM reservation that it requires? Thanks, Adrian On 22 December 2012 22:32, Adrian Chadd wrote: > Ken, > > Does CAM CTL really need to pre-allocate 35MB of RAM at startup? > > > > Adrian > > On 22 December 2012 16:45, Sergey Kandaurov wrote: >> On 23 December 2012 03:40, Marten Vijn wrote: >>> On 12/23/2012 12:27 AM, Jakub Lach wrote: >>>> >>>> Guys, I've heard about some absurd RAM requirements >>>> for 9.1, has anybody tested it? >>>> >>>> e.g. >>>> >>>> http://forums.freebsd.org/showthread.php?t=36314 >>> >>> >>> jup, I can comfirm this with nanobsd (cross) compiled >>> for my soekris net4501 which has 64 MB mem: >>> >>> from dmesg: real memory = 67108864 (64 MB) >>> >>> while the same config compiled against a 9.0 tree still works... >>> >> >> This (i.e. the "kmem_map too small" message seen with kernel memory >> shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is >> quite a big kernel memory consumer. >> Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. >> A longer term workaround could be to postpone those memory allocations >> until the first call to CTL. >> >> # cam ctl init allocates roughly 35 MB of kernel memory at once >> # three memory pools, somewhat under M_DEVBUF, and memory disk >> # devbuf takes 1022K with kern.cam.ctl.disable=1 >> >> Type InUse MemUse HighUse Requests Size(s) >> devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 >> ctlmem 5062 10113K - 5062 64,2048 >> ctlblk 200 800K - 200 4096 >> ramdisk 1 4096K - 1 >> ctlpool 532 138K - 532 16,512 >> >> -- >> wbr, >> pluknet >> _______________________________________________ >> 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 Thu Feb 28 04:35:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D935B30A for ; Thu, 28 Feb 2013 04:35:17 +0000 (UTC) (envelope-from themartininf@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id A81A9929 for ; Thu, 28 Feb 2013 04:35:17 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UAvD5-0001P9-BF for freebsd-stable@freebsd.org; Wed, 27 Feb 2013 20:35:11 -0800 Date: Wed, 27 Feb 2013 20:35:11 -0800 (PST) From: idexbsd To: freebsd-stable@freebsd.org Message-ID: <1362026111303-5791173.post@n5.nabble.com> In-Reply-To: <6eb82e0711060722g2a7876ccrd3eaf8912f5e84fa@mail.gmail.com> References: <6eb82e0711060722g2a7876ccrd3eaf8912f5e84fa@mail.gmail.com> Subject: Re: IBM xSeries 336 dual Xeon hangs on boot when APIC enabled MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 04:35:17 -0000 I tried to install "FreeBSD 9.1 AMD64" and "i386 freebsd 9.1" in an IBM xSeries 366 machine, but when the first blue screen with the "install" "shell" or "LiveCD", the screen freezes and I have to restart Freebsd forum told me I had to update the bios and then do this (1.13 to 1.17) try again ... but the result is still the same. I guess the installer needs to read some of the hard drive and unable to do this the system will stop. (This machine is implemented on RAID 1, has something to do that?) Please I need your help ... what else I can do? -- View this message in context: http://freebsd.1045724.n5.nabble.com/IBM-xSeries-336-dual-Xeon-hangs-on-boot-when-APIC-enabled-tp3941669p5791173.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 04:42:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49D82485; Thu, 28 Feb 2013 04:42:55 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8D179961; Thu, 28 Feb 2013 04:42:54 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.55]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r1S4gHE9010045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 15:12:23 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: IPMI serial console Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <990E6085-A7DC-4617-9E27-1EFB326A654F@gromit.dlib.vt.edu> Date: Thu, 28 Feb 2013 15:12:17 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <7D8169EA-89D6-4C00-AF29-69871AF18ACC@gsoft.com.au> References: <00CC60B5-A6EB-4A3C-B8AC-1D60014DE442@gsoft.com.au> <201302211049.13863.jhb@freebsd.org> <20130221220317.GA90640@icarus.home.lan> <6CD36AD055194E868054D5FC83E2AF6A@multiplay.co.uk> <7F35748E-736D-4AF1-BA6A-E831EF20396A@gsoft.com.au> <20130222001038.GA92824@icarus.home.lan> <0A4324A0-FBE3-4DD6-9670-421210D42586@gsoft.com.au> <990E6085-A7DC-4617-9E27-1EFB326A654F@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.1499) X-Spam-Score: -2.255 () ALL_TRUSTED,BAYES_00,FUZZY_VPILL,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Jeremy Chadwick , Steven Hartland , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 04:42:55 -0000 On 23/02/2013, at 24:36, Paul Mather wrote: > 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.disabled=3D"0" > hint.uart.2.flags=3D"0x30" > =3D=3D=3D=3D=3D I updated the BIOS & IPMI fiwmare and now it works. Thanks! Interestingly if you don't have hint.uart.0.flags=3D"0x0" then it goes = weird and stuff comes out the video console at 1bps.. And it seems to pick uart.0 as the console even though I also put = comconsole_port in there. So it seems that for 9.1 at least = comconsole_port doesn't DTRT. I commented it out but left the rest of = the UART hints and things still worked. > I don't know whether all of that is needed, but, as you can see from = the various commented-out lines, it was a configuration I "arrived at" = that works. :-) Yep, thanks again for taking the time as it works for me too. > Usually, I have the VGA console take precedence. In that case, I get = messages on both the VGA console and the IPMI SOL console during the = BIOS screen, loader, and kernel boot messages but then only messages on = the VGA console during the rc.d boot phase. I have a serial console = enabled in /etc/ttys, so I get output (e.g., getty login) on the IPMI = SOL when that is eventually spawned. If I want to have the serial=20 > console take precedence, I usually escape to the loader prompt (via = ESC at the loader menu) and issue a "set = console=3D"comconsole,vidconsole"" command. Then, the rc.d boot output = goes to the serial console and not the VGA console. (It would be nice = to have rc.d init scripts output go to both consoles, but I don't know = whether that is possible.) I guess the rc.d stuff goes out to whatever device is the nominal = console, rather than to the logical console which then splits the output = to all of the physical devices attached to it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 04:49:55 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07D1973A; Thu, 28 Feb 2013 04:49:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id B94D19A8; Thu, 28 Feb 2013 04:49:54 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S4nseQ090367; Thu, 28 Feb 2013 04:49:54 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S4nrN1090134; Thu, 28 Feb 2013 04:49:53 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 04:49:53 GMT Message-Id: <201302280449.r1S4nrN1090134@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:49:55 -0000 TB --- 2013-02-28 04:00:56 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 04:00:57 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 04:00:57 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2013-02-28 04:00:57 - cleaning the object tree TB --- 2013-02-28 04:00:57 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 04:00:57 - cd /tinderbox/RELENG_8/i386/pc98 TB --- 2013-02-28 04:00:57 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 04:01:08 - /usr/local/bin/svn update /src TB --- 2013-02-28 04:01:15 - building world TB --- 2013-02-28 04:01:15 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:01:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:01:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:01:15 - SRCCONF=/dev/null TB --- 2013-02-28 04:01:15 - TARGET=pc98 TB --- 2013-02-28 04:01:15 - TARGET_ARCH=i386 TB --- 2013-02-28 04:01:15 - TZ=UTC TB --- 2013-02-28 04:01:15 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:01:15 - cd /src TB --- 2013-02-28 04:01:15 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 04:01:15 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 04:46:15 UTC 2013 TB --- 2013-02-28 04:46:15 - generating LINT kernel config TB --- 2013-02-28 04:46:15 - cd /src/sys/pc98/conf TB --- 2013-02-28 04:46:15 - /usr/bin/make -B LINT TB --- 2013-02-28 04:46:16 - cd /src/sys/pc98/conf TB --- 2013-02-28 04:46:16 - /usr/sbin/config -m LINT TB --- 2013-02-28 04:46:16 - building LINT kernel TB --- 2013-02-28 04:46:16 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:46:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:46:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:46:16 - SRCCONF=/dev/null TB --- 2013-02-28 04:46:16 - TARGET=pc98 TB --- 2013-02-28 04:46:16 - TARGET_ARCH=i386 TB --- 2013-02-28 04:46:16 - TZ=UTC TB --- 2013-02-28 04:46:16 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:46:16 - cd /src TB --- 2013-02-28 04:46:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 04:46:16 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/pc98/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 04:49:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 04:49:53 - ERROR: failed to build LINT kernel TB --- 2013-02-28 04:49:53 - 2391.82 user 462.78 system 2936.43 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 04:51:20 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 26EB79B2; Thu, 28 Feb 2013 04:51:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id DDC669CC; Thu, 28 Feb 2013 04:51:19 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S4pJPh014115; Thu, 28 Feb 2013 04:51:19 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S4pJ47014095; Thu, 28 Feb 2013 04:51:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 04:51:19 GMT Message-Id: <201302280451.r1S4pJ47014095@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:51:20 -0000 TB --- 2013-02-28 04:00:56 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 04:00:57 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 04:00:57 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2013-02-28 04:00:57 - cleaning the object tree TB --- 2013-02-28 04:00:57 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 04:00:57 - cd /tinderbox/RELENG_8/i386/i386 TB --- 2013-02-28 04:00:57 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 04:01:08 - /usr/local/bin/svn update /src TB --- 2013-02-28 04:01:15 - building world TB --- 2013-02-28 04:01:15 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:01:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:01:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:01:15 - SRCCONF=/dev/null TB --- 2013-02-28 04:01:15 - TARGET=i386 TB --- 2013-02-28 04:01:15 - TARGET_ARCH=i386 TB --- 2013-02-28 04:01:15 - TZ=UTC TB --- 2013-02-28 04:01:15 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:01:15 - cd /src TB --- 2013-02-28 04:01:15 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 04:01:15 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 04:46:39 UTC 2013 TB --- 2013-02-28 04:46:39 - generating LINT kernel config TB --- 2013-02-28 04:46:39 - cd /src/sys/i386/conf TB --- 2013-02-28 04:46:39 - /usr/bin/make -B LINT TB --- 2013-02-28 04:46:39 - cd /src/sys/i386/conf TB --- 2013-02-28 04:46:39 - /usr/sbin/config -m LINT TB --- 2013-02-28 04:46:39 - building LINT kernel TB --- 2013-02-28 04:46:39 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:46:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:46:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:46:39 - SRCCONF=/dev/null TB --- 2013-02-28 04:46:39 - TARGET=i386 TB --- 2013-02-28 04:46:39 - TARGET_ARCH=i386 TB --- 2013-02-28 04:46:39 - TZ=UTC TB --- 2013-02-28 04:46:39 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:46:39 - cd /src TB --- 2013-02-28 04:46:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 04:46:39 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 04:51:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 04:51:19 - ERROR: failed to build LINT kernel TB --- 2013-02-28 04:51:19 - 2471.50 user 463.08 system 3022.43 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 05:03:35 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD823DF5; Thu, 28 Feb 2013 05:03:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 7D31DA45; Thu, 28 Feb 2013 05:03:35 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S53Z0o011571; Thu, 28 Feb 2013 05:03:35 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S53ZOQ011570; Thu, 28 Feb 2013 05:03:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 05:03:35 GMT Message-Id: <201302280503.r1S53ZOQ011570@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:03:35 -0000 TB --- 2013-02-28 04:00:56 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 04:00:57 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 04:00:57 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2013-02-28 04:00:57 - cleaning the object tree TB --- 2013-02-28 04:00:57 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 04:00:57 - cd /tinderbox/RELENG_8/ia64/ia64 TB --- 2013-02-28 04:00:57 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 04:01:08 - /usr/local/bin/svn update /src TB --- 2013-02-28 04:01:15 - building world TB --- 2013-02-28 04:01:15 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:01:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:01:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:01:15 - SRCCONF=/dev/null TB --- 2013-02-28 04:01:15 - TARGET=ia64 TB --- 2013-02-28 04:01:15 - TARGET_ARCH=ia64 TB --- 2013-02-28 04:01:15 - TZ=UTC TB --- 2013-02-28 04:01:15 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:01:15 - cd /src TB --- 2013-02-28 04:01:15 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 04:01:15 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 04:59:21 UTC 2013 TB --- 2013-02-28 04:59:21 - generating LINT kernel config TB --- 2013-02-28 04:59:21 - cd /src/sys/ia64/conf TB --- 2013-02-28 04:59:21 - /usr/bin/make -B LINT TB --- 2013-02-28 04:59:21 - cd /src/sys/ia64/conf TB --- 2013-02-28 04:59:21 - /usr/sbin/config -m LINT TB --- 2013-02-28 04:59:21 - building LINT kernel TB --- 2013-02-28 04:59:21 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:59:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:59:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:59:21 - SRCCONF=/dev/null TB --- 2013-02-28 04:59:21 - TARGET=ia64 TB --- 2013-02-28 04:59:21 - TARGET_ARCH=ia64 TB --- 2013-02-28 04:59:21 - TZ=UTC TB --- 2013-02-28 04:59:21 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:59:21 - cd /src TB --- 2013-02-28 04:59:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 04:59:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 05:03:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 05:03:35 - ERROR: failed to build LINT kernel TB --- 2013-02-28 05:03:35 - 3219.02 user 476.90 system 3758.08 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 05:10:29 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 636A5FA5; Thu, 28 Feb 2013 05:10:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 2399FA82; Thu, 28 Feb 2013 05:10:29 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S5ASKj099227; Thu, 28 Feb 2013 05:10:28 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S5ASdk099226; Thu, 28 Feb 2013 05:10:28 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 05:10:28 GMT Message-Id: <201302280510.r1S5ASdk099226@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:10:29 -0000 TB --- 2013-02-28 04:00:57 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 04:00:57 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 04:00:57 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2013-02-28 04:00:57 - cleaning the object tree TB --- 2013-02-28 04:00:57 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 04:00:57 - cd /tinderbox/RELENG_8/amd64/amd64 TB --- 2013-02-28 04:00:57 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 04:01:08 - /usr/local/bin/svn update /src TB --- 2013-02-28 04:01:15 - building world TB --- 2013-02-28 04:01:15 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:01:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:01:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:01:15 - SRCCONF=/dev/null TB --- 2013-02-28 04:01:15 - TARGET=amd64 TB --- 2013-02-28 04:01:15 - TARGET_ARCH=amd64 TB --- 2013-02-28 04:01:15 - TZ=UTC TB --- 2013-02-28 04:01:15 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:01:15 - cd /src TB --- 2013-02-28 04:01:15 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 04:01:15 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Feb 28 05:06:24 UTC 2013 TB --- 2013-02-28 05:06:24 - generating LINT kernel config TB --- 2013-02-28 05:06:24 - cd /src/sys/amd64/conf TB --- 2013-02-28 05:06:24 - /usr/bin/make -B LINT TB --- 2013-02-28 05:06:24 - cd /src/sys/amd64/conf TB --- 2013-02-28 05:06:24 - /usr/sbin/config -m LINT TB --- 2013-02-28 05:06:24 - building LINT kernel TB --- 2013-02-28 05:06:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 05:06:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 05:06:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 05:06:24 - SRCCONF=/dev/null TB --- 2013-02-28 05:06:24 - TARGET=amd64 TB --- 2013-02-28 05:06:24 - TARGET_ARCH=amd64 TB --- 2013-02-28 05:06:24 - TZ=UTC TB --- 2013-02-28 05:06:24 - __MAKE_CONF=/dev/null TB --- 2013-02-28 05:06:24 - cd /src TB --- 2013-02-28 05:06:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 05:06:24 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 05:10:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 05:10:28 - ERROR: failed to build LINT kernel TB --- 2013-02-28 05:10:28 - 3423.88 user 663.28 system 4171.71 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 05:33:07 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1058371C; Thu, 28 Feb 2013 05:33:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id C5491B40; Thu, 28 Feb 2013 05:33:06 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S5X6RH067274; Thu, 28 Feb 2013 05:33:06 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S5X64R067273; Thu, 28 Feb 2013 05:33:06 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 05:33:06 GMT Message-Id: <201302280533.r1S5X64R067273@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:33:07 -0000 TB --- 2013-02-28 04:51:19 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 04:51:19 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 04:51:19 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2013-02-28 04:51:19 - cleaning the object tree TB --- 2013-02-28 04:51:39 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 04:51:39 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2013-02-28 04:51:39 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 04:51:46 - /usr/local/bin/svn update /src TB --- 2013-02-28 04:51:50 - building world TB --- 2013-02-28 04:51:50 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:51:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:51:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:51:50 - SRCCONF=/dev/null TB --- 2013-02-28 04:51:50 - TARGET=sparc64 TB --- 2013-02-28 04:51:50 - TARGET_ARCH=sparc64 TB --- 2013-02-28 04:51:50 - TZ=UTC TB --- 2013-02-28 04:51:50 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:51:50 - cd /src TB --- 2013-02-28 04:51:50 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 04:51:50 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 05:30:24 UTC 2013 TB --- 2013-02-28 05:30:24 - generating LINT kernel config TB --- 2013-02-28 05:30:24 - cd /src/sys/sparc64/conf TB --- 2013-02-28 05:30:24 - /usr/bin/make -B LINT TB --- 2013-02-28 05:30:24 - cd /src/sys/sparc64/conf TB --- 2013-02-28 05:30:24 - /usr/sbin/config -m LINT TB --- 2013-02-28 05:30:24 - building LINT kernel TB --- 2013-02-28 05:30:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 05:30:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 05:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 05:30:24 - SRCCONF=/dev/null TB --- 2013-02-28 05:30:24 - TARGET=sparc64 TB --- 2013-02-28 05:30:24 - TARGET_ARCH=sparc64 TB --- 2013-02-28 05:30:24 - TZ=UTC TB --- 2013-02-28 05:30:24 - __MAKE_CONF=/dev/null TB --- 2013-02-28 05:30:24 - cd /src TB --- 2013-02-28 05:30:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 05:30:24 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 05:33:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 05:33:06 - ERROR: failed to build LINT kernel TB --- 2013-02-28 05:33:06 - 2120.11 user 371.68 system 2506.68 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 05:33:40 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CECFF835; Thu, 28 Feb 2013 05:33:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE27B53; Thu, 28 Feb 2013 05:33:40 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S5XeSg067702; Thu, 28 Feb 2013 05:33:40 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S5XeC4067701; Thu, 28 Feb 2013 05:33:40 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 05:33:40 GMT Message-Id: <201302280533.r1S5XeC4067701@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:33:40 -0000 TB --- 2013-02-28 04:49:54 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 04:49:54 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 04:49:54 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2013-02-28 04:49:54 - cleaning the object tree TB --- 2013-02-28 04:50:12 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 04:50:12 - cd /tinderbox/RELENG_8/powerpc/powerpc TB --- 2013-02-28 04:50:12 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 04:50:19 - /usr/local/bin/svn update /src TB --- 2013-02-28 04:50:23 - building world TB --- 2013-02-28 04:50:23 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 04:50:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 04:50:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 04:50:23 - SRCCONF=/dev/null TB --- 2013-02-28 04:50:23 - TARGET=powerpc TB --- 2013-02-28 04:50:23 - TARGET_ARCH=powerpc TB --- 2013-02-28 04:50:23 - TZ=UTC TB --- 2013-02-28 04:50:23 - __MAKE_CONF=/dev/null TB --- 2013-02-28 04:50:23 - cd /src TB --- 2013-02-28 04:50:23 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 04:50:23 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 05:31:08 UTC 2013 TB --- 2013-02-28 05:31:08 - generating LINT kernel config TB --- 2013-02-28 05:31:08 - cd /src/sys/powerpc/conf TB --- 2013-02-28 05:31:08 - /usr/bin/make -B LINT TB --- 2013-02-28 05:31:08 - cd /src/sys/powerpc/conf TB --- 2013-02-28 05:31:08 - /usr/sbin/config -m LINT TB --- 2013-02-28 05:31:08 - building LINT kernel TB --- 2013-02-28 05:31:08 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 05:31:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 05:31:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 05:31:08 - SRCCONF=/dev/null TB --- 2013-02-28 05:31:08 - TARGET=powerpc TB --- 2013-02-28 05:31:08 - TARGET_ARCH=powerpc TB --- 2013-02-28 05:31:08 - TZ=UTC TB --- 2013-02-28 05:31:08 - __MAKE_CONF=/dev/null TB --- 2013-02-28 05:31:08 - cd /src TB --- 2013-02-28 05:31:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 05:31:08 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 05:33:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 05:33:40 - ERROR: failed to build LINT kernel TB --- 2013-02-28 05:33:40 - 2229.38 user 376.94 system 2625.76 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 05:36:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AB2769FB; Thu, 28 Feb 2013 05:36:32 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) by mx1.freebsd.org (Postfix) with ESMTP id 2F339BD6; Thu, 28 Feb 2013 05:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=nQHKl3uy9ECXLp96TpVuLrZaCGL6e8aQk2i+G0oJgqM=; b=czY7DtmaFWRkWgqAUL4MLzRF4s04wGS77m17sQbY4t3WlVuYhedbfMmqOPTeYRApEAw5OhJSgomrFsKY99VAnPFT35EgyTL+oGUXgIC+EWZUl57hRFzaOERdWQorOitf; Received: from [217.25.27.27] (port=20819) by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1UAwAJ-0006Rt-AJ; Thu, 28 Feb 2013 09:36:23 +0400 Message-ID: <512EECD4.5080600@mail.ru> Date: Thu, 28 Feb 2013 09:36:20 +0400 From: rihad User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: mfi timeouts References: <512CFF90.8080806@mail.ru> <201302261548.56253.jhb@freebsd.org> <512DA073.9090908@mail.ru> <201302271159.13424.jhb@freebsd.org> In-Reply-To: <201302271159.13424.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 05:36:32 -0000 On 02/27/2013 08:59 PM, John Baldwin wrote: > On Wednesday, February 27, 2013 12:58:11 am rihad wrote: >> Now about this part taken from here >> http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html >> > By issuing a dummy read operation (thus forcing a flush of data >> buffers), this issue is largely averted. >> >> Does this mean that battery-backed cache (BBU) is effectively rendered >> useless, as all write operations are forced on to the disk platters on >> every interrupt? > No, this is a very different level. This is forcing pending PCI DMA > transactions on the PCI bus to flush by doing a read, not forcing I/O > buffers to be flushed to disk. > Thanks for clarifying. After applying the "dummy read" patch mfi timeouts don't appear in dmesg output any more, but i/o stalls still occurred 2-3 times during periods of high activity, for no more than 10-20 seconds. I guess the only way to fix that is to choose another hardware RAID implementation, or try Steven Hartland's patch? Does 8.3 or 9.1 include more fixes in this area, is upgrading recommended? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 07:45:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61597E7; Thu, 28 Feb 2013 07:45:12 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id CA46E1017; Thu, 28 Feb 2013 07:45:11 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id d7so1253369wer.22 for ; Wed, 27 Feb 2013 23:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CNRkn/IcgJb97t+vkbqGfhkrB+qC7RQ3B8SG/mRBJh0=; b=QQV18sG2Prd/rIKqgYHqMNuDGlQFxXq2i2wMJMUI45Tz9pgAG6URt10Myv1oMljwaP M/PzSiW0YlsN53wklVsLo0qKTxC7YEs4eQKxMIrQ5L1B+GBehz3Y11PNGm/CpyHWWEJ0 db0WlqkklK9eZ6zogfeppre8gqeVgIQoZyzmVA6cpVpqYVG5nuAoofL4z/1mV9Yd9YuK wyxh2PMhbQdks7K7nV+qovmPGvs6nfbUPa9CKk5LpkRzL3XOrNrQxkfeS5WkfLM7GS9E aC2CEG1gjQyO+Rrypd0pH9BmYPuHwUH4fwtvGSTKQuMvwBAJQM3tUoRenA6x8jswgNJl 0K/g== MIME-Version: 1.0 X-Received: by 10.194.81.40 with SMTP id w8mr8903219wjx.14.1362037511090; Wed, 27 Feb 2013 23:45:11 -0800 (PST) Received: by 10.194.13.230 with HTTP; Wed, 27 Feb 2013 23:45:11 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Feb 2013 08:45:11 +0100 Message-ID: Subject: Re: rc.d/sysctl fails to parse sysctl.conf From: Andreas Nilsson To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 07:45:12 -0000 On Wed, Feb 27, 2013 at 10:39 PM, Chris Rees wrote: > On 27 February 2013 21:19, Andreas Nilsson wrote: > > Hello, > > > > I tried to get my sound working, and long story short: rc.d/sysctl parses > > sysctl.conf wrongly if there are sysctls of the form > > > > mib=val1=val2 > > > > which is what you need for sound. For reference I needed/wanted > > > > dev.hdaa.4.nid25_config=as=1,seq=15 > > dev.hdaa.4.nid31_config=as=1 > > > > I believe the following patch would address the incorrect parsing: > > > > --- /etc/rc.d/sysctl.old 2013-02-27 22:00:00.000000000 +0100 > > +++ /etc/rc.d/sysctl 2013-02-27 22:05:24.000000000 +0100 > > @@ -26,7 +26,7 @@ > > \#*|'') > > ;; > > *) > > - mib=${var%=*} > > + mib=${var%%=*} > > val=${var#*=} > > > > if current_value=`${SYSCTL} -n ${mib} > > 2>/dev/null`; then > > I think that this is the right thing to do here. > > Chris > As a follow-up question: is sysctl.conf supposed to handle all valid input one can give sysctl on the command line? Using the above example would normally be typed: sysctl dev.hdaa.4.nid25_config="as=1 seq=15" which works, but fails to work from sysctl.conf Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:00:36 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8EE87375; Thu, 28 Feb 2013 08:00:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4E710B4; Thu, 28 Feb 2013 08:00:36 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S80ZoG042457; Thu, 28 Feb 2013 08:00:35 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S80ZY2042446; Thu, 28 Feb 2013 08:00:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 08:00:35 GMT Message-Id: <201302280800.r1S80ZY2042446@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:00:36 -0000 TB --- 2013-02-28 07:10:41 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 07:10:41 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 07:10:41 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2013-02-28 07:10:41 - cleaning the object tree TB --- 2013-02-28 07:11:44 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 07:11:44 - cd /tinderbox/RELENG_8/i386/pc98 TB --- 2013-02-28 07:11:44 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 07:11:58 - /usr/local/bin/svn update /src TB --- 2013-02-28 07:12:03 - building world TB --- 2013-02-28 07:12:03 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 07:12:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 07:12:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 07:12:03 - SRCCONF=/dev/null TB --- 2013-02-28 07:12:03 - TARGET=pc98 TB --- 2013-02-28 07:12:03 - TARGET_ARCH=i386 TB --- 2013-02-28 07:12:03 - TZ=UTC TB --- 2013-02-28 07:12:03 - __MAKE_CONF=/dev/null TB --- 2013-02-28 07:12:03 - cd /src TB --- 2013-02-28 07:12:03 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 07:12:03 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 07:56:57 UTC 2013 TB --- 2013-02-28 07:56:57 - generating LINT kernel config TB --- 2013-02-28 07:56:57 - cd /src/sys/pc98/conf TB --- 2013-02-28 07:56:57 - /usr/bin/make -B LINT TB --- 2013-02-28 07:56:57 - cd /src/sys/pc98/conf TB --- 2013-02-28 07:56:57 - /usr/sbin/config -m LINT TB --- 2013-02-28 07:56:57 - building LINT kernel TB --- 2013-02-28 07:56:57 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 07:56:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 07:56:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 07:56:57 - SRCCONF=/dev/null TB --- 2013-02-28 07:56:57 - TARGET=pc98 TB --- 2013-02-28 07:56:57 - TARGET_ARCH=i386 TB --- 2013-02-28 07:56:57 - TZ=UTC TB --- 2013-02-28 07:56:57 - __MAKE_CONF=/dev/null TB --- 2013-02-28 07:56:57 - cd /src TB --- 2013-02-28 07:56:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 07:56:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/pc98/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 08:00:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 08:00:35 - ERROR: failed to build LINT kernel TB --- 2013-02-28 08:00:35 - 2394.61 user 461.77 system 2993.95 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:02:00 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B92349C; Thu, 28 Feb 2013 08:02:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0B510D2; Thu, 28 Feb 2013 08:02:00 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S81xov065498; Thu, 28 Feb 2013 08:01:59 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S81xHX065493; Thu, 28 Feb 2013 08:01:59 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 08:01:59 GMT Message-Id: <201302280801.r1S81xHX065493@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:02:00 -0000 TB --- 2013-02-28 07:10:41 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 07:10:41 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 07:10:41 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2013-02-28 07:10:41 - cleaning the object tree TB --- 2013-02-28 07:11:43 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 07:11:43 - cd /tinderbox/RELENG_8/i386/i386 TB --- 2013-02-28 07:11:43 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 07:11:58 - /usr/local/bin/svn update /src TB --- 2013-02-28 07:12:03 - building world TB --- 2013-02-28 07:12:03 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 07:12:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 07:12:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 07:12:03 - SRCCONF=/dev/null TB --- 2013-02-28 07:12:03 - TARGET=i386 TB --- 2013-02-28 07:12:03 - TARGET_ARCH=i386 TB --- 2013-02-28 07:12:03 - TZ=UTC TB --- 2013-02-28 07:12:03 - __MAKE_CONF=/dev/null TB --- 2013-02-28 07:12:03 - cd /src TB --- 2013-02-28 07:12:03 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 07:12:03 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 07:57:20 UTC 2013 TB --- 2013-02-28 07:57:20 - generating LINT kernel config TB --- 2013-02-28 07:57:20 - cd /src/sys/i386/conf TB --- 2013-02-28 07:57:20 - /usr/bin/make -B LINT TB --- 2013-02-28 07:57:20 - cd /src/sys/i386/conf TB --- 2013-02-28 07:57:20 - /usr/sbin/config -m LINT TB --- 2013-02-28 07:57:20 - building LINT kernel TB --- 2013-02-28 07:57:20 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 07:57:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 07:57:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 07:57:20 - SRCCONF=/dev/null TB --- 2013-02-28 07:57:20 - TARGET=i386 TB --- 2013-02-28 07:57:20 - TARGET_ARCH=i386 TB --- 2013-02-28 07:57:20 - TZ=UTC TB --- 2013-02-28 07:57:20 - __MAKE_CONF=/dev/null TB --- 2013-02-28 07:57:20 - cd /src TB --- 2013-02-28 07:57:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 07:57:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 08:01:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 08:01:59 - ERROR: failed to build LINT kernel TB --- 2013-02-28 08:01:59 - 2468.83 user 464.92 system 3078.11 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:09:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E59D59CD for ; Thu, 28 Feb 2013 08:09:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id CB94D1155 for ; Thu, 28 Feb 2013 08:09:35 +0000 (UTC) Received: from Xins-MacBook-Pro-2.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 7329724B1C; Thu, 28 Feb 2013 00:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1362038975; bh=CBB+UDJ3WSvPa1wO2yK3trJ1MCW8Db0ehX+Xdi7DcAY=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=b+8//DEhc9WhnHEgB7ivek7xjl9+zeg6t1Lls/41o/ZG4vVPuyLT+u1vaot1jYRUP 3eOOPPaSI2vUdpPIg5VtyMfEVQUhGFlXxmA4JqB2sNlRN6/5c2E4FCNOu8t90XOV4w 0EfSzV82YZyaNHdGPRWRqd0fysx+6OGsiAoombeY= Message-ID: <512F10BE.7060404@delphij.net> Date: Thu, 28 Feb 2013 00:09:34 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Andreas Nilsson Subject: Re: rc.d/sysctl fails to parse sysctl.conf References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:09:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have committed this change to 9-STABLE directly, the code gets refactored in -HEAD and solved differently. Thanks for your submission! Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRLxC+AAoJEG80Jeu8UPuzY3kH/2MmuE6bqRC2hnznPOTt+w9m f+ojdHTQvPkx2c6S+ONv/rJuwIuJxH+4Lc6ZrMRpSnZMuq6RuGFuKG1+q+0uwLT4 bYh8YvcA5xGnomkCkCVll/BSlVQFtixsecGlW6HKUXZTc0ivUrkR1EUJP4A6ns3c 9Sg+ENL0swXRIdGWGKzDMoA3k50k4FB7EyxkKy1DIsk/XuUi7TpnU9abNo2uL0UW jBfOBlGK7F4QothboBbm1RYTrGVfZKkqW6E3G/KMA795HWhmlObZh0lF6DBMR0mP HoiHwbyuRC6tC/Y19kUiTMXvCtnsN5CADhQmn6ymvkdhrzQN1ZMbFN6UrPvAW2U= =s0jR -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:13:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9DE7CCC0 for ; Thu, 28 Feb 2013 08:13:30 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 824D11188 for ; Thu, 28 Feb 2013 08:13:30 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 5kA71l00117UAYkA7kDWqF; Thu, 28 Feb 2013 08:13:30 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id 5kDV1l0061t3BNj8ZkDVXk; Thu, 28 Feb 2013 08:13:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 22D6373A31; Thu, 28 Feb 2013 00:13:29 -0800 (PST) Date: Thu, 28 Feb 2013 00:13:29 -0800 From: Jeremy Chadwick To: Andreas Nilsson Subject: Re: rc.d/sysctl fails to parse sysctl.conf Message-ID: <20130228081329.GA6194@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362039210; bh=/c2GCSdvVgV8Raiw+bAHBPssCaaX6nWRV9g8HJJp0tk=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=HCvg9wV7nKvJtAn880ufwospSniMIwDWqUmE3iA1RyUowhVw6rbM40L63LVUxt+aN 2TN4s4c6nLRrCEVFhXcIkF4iuiKO/XgjXTyHlesRj0QariUTnQnhy5w60BFYesDOMb Bmy+yfbpm7AHh/g8d6a9v41rwadINtNI5M2566GGzEzc1SS7HWvouNhWDWRXSCfg9V Kr9hpy5A6ewOXXGw4v8+MFCMhePofKHNW4CrRc+6BQWDQ2ZvvHTzWqp/FqK0VKiERy JuNsfJAg3tpaDC7QohNEHGxAglStYVjGnM1a+q5RKJ/rlQOtoeKb2uPacow6YrFUg2 whWLHtdk13hqw== Cc: Chris Rees , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 08:13:30 -0000 On Thu, Feb 28, 2013 at 08:45:11AM +0100, Andreas Nilsson wrote: > On Wed, Feb 27, 2013 at 10:39 PM, Chris Rees wrote: > > > On 27 February 2013 21:19, Andreas Nilsson wrote: > > > Hello, > > > > > > I tried to get my sound working, and long story short: rc.d/sysctl parses > > > sysctl.conf wrongly if there are sysctls of the form > > > > > > mib=val1=val2 > > > > > > which is what you need for sound. For reference I needed/wanted > > > > > > dev.hdaa.4.nid25_config=as=1,seq=15 > > > dev.hdaa.4.nid31_config=as=1 > > > > > > I believe the following patch would address the incorrect parsing: > > > > > > --- /etc/rc.d/sysctl.old 2013-02-27 22:00:00.000000000 +0100 > > > +++ /etc/rc.d/sysctl 2013-02-27 22:05:24.000000000 +0100 > > > @@ -26,7 +26,7 @@ > > > \#*|'') > > > ;; > > > *) > > > - mib=${var%=*} > > > + mib=${var%%=*} > > > val=${var#*=} > > > > > > if current_value=`${SYSCTL} -n ${mib} > > > 2>/dev/null`; then > > > > I think that this is the right thing to do here. > > > > Chris > > As a follow-up question: is sysctl.conf supposed to handle all valid input > one can give sysctl on the command line? Using the above example would > normally be typed: > sysctl dev.hdaa.4.nid25_config="as=1 seq=15" > which works, but fails to work from sysctl.conf This has to do with how your shell parses things (quotes, etc.) versus how shell scripts like /etc/rc.d/sysctl do. Assuming you read/speak sh: read /etc/rc.d/sysctl. It's not very long, and fairly easy to follow, barring the %, %%, and # pattern modifier parts (read sh man page for how those work). /etc/rc.d/sysctl is not a "file parser" -- instead it relies on sh to do the work. Once you read the script, you'll understand how/why apostrophes, double quotes, and spaces in /etc/sysctl.conf are a problem. "Solving" this dilemma in sh is a pain in the ass and often involves utter nonsense like escaping (\) every character and making exceptions; folks who have written extensive shell scripts will know what I mean when I use the term "quoting hell". That said, here's the general guideline: your /etc/sysctl.conf should not contain quotes or double-quotes or spaces after the assignment (=), generally speaking. If there is a sysctl MIB that actually ***requires*** spaces in its value, then whoever coded their driver/bit that way should be taken out back and flogged. Hard. This is why you probably see Andreas using a comma-delimited model (and if that works, fantastic+great!). That said: you can get spaces to work in /etc/sysctl.conf by escaping them, i.e.: some.mib=foo\ bar You might be able to escape some types of quotes, but this gets into "quoting hell" like I said above. Don't bother. As I said, apostrophes (') and double-quotes (") and spaces (" "), will cause problems, and if you read the script it'll become apparent why. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:14:20 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C84B7DBD; Thu, 28 Feb 2013 08:14:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 85BAE119B; Thu, 28 Feb 2013 08:14:20 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S8EKW3064199; Thu, 28 Feb 2013 08:14:20 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S8EKNw064197; Thu, 28 Feb 2013 08:14:20 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 08:14:20 GMT Message-Id: <201302280814.r1S8EKNw064197@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:14:20 -0000 TB --- 2013-02-28 07:10:41 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 07:10:41 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 07:10:41 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2013-02-28 07:10:41 - cleaning the object tree TB --- 2013-02-28 07:11:39 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 07:11:39 - cd /tinderbox/RELENG_8/ia64/ia64 TB --- 2013-02-28 07:11:39 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 07:11:57 - /usr/local/bin/svn update /src TB --- 2013-02-28 07:12:02 - building world TB --- 2013-02-28 07:12:02 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 07:12:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 07:12:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 07:12:02 - SRCCONF=/dev/null TB --- 2013-02-28 07:12:02 - TARGET=ia64 TB --- 2013-02-28 07:12:02 - TARGET_ARCH=ia64 TB --- 2013-02-28 07:12:02 - TZ=UTC TB --- 2013-02-28 07:12:02 - __MAKE_CONF=/dev/null TB --- 2013-02-28 07:12:02 - cd /src TB --- 2013-02-28 07:12:02 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 07:12:02 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 08:10:07 UTC 2013 TB --- 2013-02-28 08:10:07 - generating LINT kernel config TB --- 2013-02-28 08:10:07 - cd /src/sys/ia64/conf TB --- 2013-02-28 08:10:07 - /usr/bin/make -B LINT TB --- 2013-02-28 08:10:07 - cd /src/sys/ia64/conf TB --- 2013-02-28 08:10:07 - /usr/sbin/config -m LINT TB --- 2013-02-28 08:10:07 - building LINT kernel TB --- 2013-02-28 08:10:07 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 08:10:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 08:10:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 08:10:07 - SRCCONF=/dev/null TB --- 2013-02-28 08:10:07 - TARGET=ia64 TB --- 2013-02-28 08:10:07 - TARGET_ARCH=ia64 TB --- 2013-02-28 08:10:07 - TZ=UTC TB --- 2013-02-28 08:10:07 - __MAKE_CONF=/dev/null TB --- 2013-02-28 08:10:07 - cd /src TB --- 2013-02-28 08:10:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 08:10:07 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 08:14:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 08:14:20 - ERROR: failed to build LINT kernel TB --- 2013-02-28 08:14:20 - 3213.04 user 482.83 system 3818.23 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:21:09 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18F98174; Thu, 28 Feb 2013 08:21:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id CF15411E6; Thu, 28 Feb 2013 08:21:08 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S8L8Tp051099; Thu, 28 Feb 2013 08:21:08 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S8L8FT051094; Thu, 28 Feb 2013 08:21:08 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 08:21:08 GMT Message-Id: <201302280821.r1S8L8FT051094@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:21:09 -0000 TB --- 2013-02-28 07:10:41 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 07:10:41 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 07:10:41 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2013-02-28 07:10:41 - cleaning the object tree TB --- 2013-02-28 07:11:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 07:11:49 - cd /tinderbox/RELENG_8/amd64/amd64 TB --- 2013-02-28 07:11:49 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 07:12:02 - /usr/local/bin/svn update /src TB --- 2013-02-28 07:12:07 - building world TB --- 2013-02-28 07:12:07 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 07:12:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 07:12:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 07:12:07 - SRCCONF=/dev/null TB --- 2013-02-28 07:12:07 - TARGET=amd64 TB --- 2013-02-28 07:12:07 - TARGET_ARCH=amd64 TB --- 2013-02-28 07:12:07 - TZ=UTC TB --- 2013-02-28 07:12:07 - __MAKE_CONF=/dev/null TB --- 2013-02-28 07:12:07 - cd /src TB --- 2013-02-28 07:12:07 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 07:12:07 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Feb 28 08:17:05 UTC 2013 TB --- 2013-02-28 08:17:05 - generating LINT kernel config TB --- 2013-02-28 08:17:05 - cd /src/sys/amd64/conf TB --- 2013-02-28 08:17:05 - /usr/bin/make -B LINT TB --- 2013-02-28 08:17:05 - cd /src/sys/amd64/conf TB --- 2013-02-28 08:17:05 - /usr/sbin/config -m LINT TB --- 2013-02-28 08:17:05 - building LINT kernel TB --- 2013-02-28 08:17:05 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 08:17:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 08:17:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 08:17:05 - SRCCONF=/dev/null TB --- 2013-02-28 08:17:05 - TARGET=amd64 TB --- 2013-02-28 08:17:05 - TARGET_ARCH=amd64 TB --- 2013-02-28 08:17:05 - TZ=UTC TB --- 2013-02-28 08:17:05 - __MAKE_CONF=/dev/null TB --- 2013-02-28 08:17:05 - cd /src TB --- 2013-02-28 08:17:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 08:17:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 08:21:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 08:21:08 - ERROR: failed to build LINT kernel TB --- 2013-02-28 08:21:08 - 3420.18 user 665.77 system 4226.58 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:27:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0CDFB424 for ; Thu, 28 Feb 2013 08:27:57 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id D387E1244 for ; Thu, 28 Feb 2013 08:27:56 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 5kRV1l0041vN32cA3kTwSn; Thu, 28 Feb 2013 08:27:56 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id 5kTv1l00G1t3BNj8ikTvS6; Thu, 28 Feb 2013 08:27:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AF24B73A31; Thu, 28 Feb 2013 00:27:55 -0800 (PST) Date: Thu, 28 Feb 2013 00:27:55 -0800 From: Jeremy Chadwick To: Jack Vogel Subject: Re: [releng_8 tinderbox] failure on amd64/amd64 Message-ID: <20130228082755.GA6756@icarus.home.lan> References: <201302280821.r1S8L8FT051094@freebsd-legacy2.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302280821.r1S8L8FT051094@freebsd-legacy2.sentex.ca> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362040076; bh=KTbNEdvg0/u8SsFZ+GH8klqAupwL4RT27so5c11ChoQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=nNmx3hyB0HgkMgkXzNa5pzStqiPEhEK8vBDC+kuqaRoQ4leSobPC0wuS/C/1YErRm Yr6jtAWWSuhSgsnn7tmjW9SrM05yd4yTrzCmCoQSCTayWvAm4JXMbBLW9claq4G4Fe CqzMQ7tDnSlmof5BL8de3cz891cPXCSKl7r1XPrwyTlhPeV7ieKadvqb0kvNUhClLx mmGTzyYk7YFRQk/HtpI6gmOBLfLBT7yPQPcru+MVakH5qUs0s4mh4Mx/TlxuBFDLBu Qrdx4XnJz7u1oqLVRFaOiFhTqjV6at3Q0aBSg7EaMUBt24QulVQmEJplmHe0eo7gCA 3cHOtSI/gurQw== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 08:27:57 -0000 (Apologies for top-posting, just being quick about this one) Jack, This looks like fallout from commit r247430 to stable/8: http://svnweb.freebsd.org/base/stable/8/sys/dev/e1000/if_em.c -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | On Thu, Feb 28, 2013 at 08:21:08AM +0000, FreeBSD Tinderbox wrote: > TB --- 2013-02-28 07:10:41 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca > TB --- 2013-02-28 07:10:41 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-02-28 07:10:41 - starting RELENG_8 tinderbox run for amd64/amd64 > TB --- 2013-02-28 07:10:41 - cleaning the object tree > TB --- 2013-02-28 07:11:49 - checking out /src from svn://svn.freebsd.org/base/stable/8 > TB --- 2013-02-28 07:11:49 - cd /tinderbox/RELENG_8/amd64/amd64 > TB --- 2013-02-28 07:11:49 - /usr/local/bin/svn cleanup /src > TB --- 2013-02-28 07:12:02 - /usr/local/bin/svn update /src > TB --- 2013-02-28 07:12:07 - building world > TB --- 2013-02-28 07:12:07 - CROSS_BUILD_TESTING=YES > TB --- 2013-02-28 07:12:07 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-02-28 07:12:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-02-28 07:12:07 - SRCCONF=/dev/null > TB --- 2013-02-28 07:12:07 - TARGET=amd64 > TB --- 2013-02-28 07:12:07 - TARGET_ARCH=amd64 > TB --- 2013-02-28 07:12:07 - TZ=UTC > TB --- 2013-02-28 07:12:07 - __MAKE_CONF=/dev/null > TB --- 2013-02-28 07:12:07 - cd /src > TB --- 2013-02-28 07:12:07 - /usr/bin/make -B buildworld > >>> World build started on Thu Feb 28 07:12:07 UTC 2013 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Thu Feb 28 08:17:05 UTC 2013 > TB --- 2013-02-28 08:17:05 - generating LINT kernel config > TB --- 2013-02-28 08:17:05 - cd /src/sys/amd64/conf > TB --- 2013-02-28 08:17:05 - /usr/bin/make -B LINT > TB --- 2013-02-28 08:17:05 - cd /src/sys/amd64/conf > TB --- 2013-02-28 08:17:05 - /usr/sbin/config -m LINT > TB --- 2013-02-28 08:17:05 - building LINT kernel > TB --- 2013-02-28 08:17:05 - CROSS_BUILD_TESTING=YES > TB --- 2013-02-28 08:17:05 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-02-28 08:17:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-02-28 08:17:05 - SRCCONF=/dev/null > TB --- 2013-02-28 08:17:05 - TARGET=amd64 > TB --- 2013-02-28 08:17:05 - TARGET_ARCH=amd64 > TB --- 2013-02-28 08:17:05 - TZ=UTC > TB --- 2013-02-28 08:17:05 - __MAKE_CONF=/dev/null > TB --- 2013-02-28 08:17:05 - cd /src > TB --- 2013-02-28 08:17:05 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Thu Feb 28 08:17:05 UTC 2013 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc1: warnings being treated as errors > /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': > /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' > /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' > /src/sys/dev/e1000/if_em.c: In function 'em_txeof': > /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' > /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': > /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' > *** [if_em.o] Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** [buildkernel] Error code 1 > > Stop in /src. > *** [buildkernel] Error code 1 > > Stop in /src. > TB --- 2013-02-28 08:21:08 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-02-28 08:21:08 - ERROR: failed to build LINT kernel > TB --- 2013-02-28 08:21:08 - 3420.18 user 665.77 system 4226.58 real > > > http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full > _______________________________________________ > 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 Thu Feb 28 08:43:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D0BB9D0; Thu, 28 Feb 2013 08:43:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id C0F8514A1; Thu, 28 Feb 2013 08:43:41 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S8hfPm018228; Thu, 28 Feb 2013 08:43:41 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S8hfxs018227; Thu, 28 Feb 2013 08:43:41 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 08:43:41 GMT Message-Id: <201302280843.r1S8hfxs018227@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:43:42 -0000 TB --- 2013-02-28 08:02:00 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 08:02:00 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 08:02:00 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2013-02-28 08:02:00 - cleaning the object tree TB --- 2013-02-28 08:02:19 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 08:02:19 - cd /tinderbox/RELENG_8/sparc64/sparc64 TB --- 2013-02-28 08:02:19 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 08:02:26 - /usr/local/bin/svn update /src TB --- 2013-02-28 08:02:31 - building world TB --- 2013-02-28 08:02:31 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 08:02:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 08:02:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 08:02:31 - SRCCONF=/dev/null TB --- 2013-02-28 08:02:31 - TARGET=sparc64 TB --- 2013-02-28 08:02:31 - TARGET_ARCH=sparc64 TB --- 2013-02-28 08:02:31 - TZ=UTC TB --- 2013-02-28 08:02:31 - __MAKE_CONF=/dev/null TB --- 2013-02-28 08:02:31 - cd /src TB --- 2013-02-28 08:02:31 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 08:02:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 08:41:01 UTC 2013 TB --- 2013-02-28 08:41:01 - generating LINT kernel config TB --- 2013-02-28 08:41:01 - cd /src/sys/sparc64/conf TB --- 2013-02-28 08:41:01 - /usr/bin/make -B LINT TB --- 2013-02-28 08:41:01 - cd /src/sys/sparc64/conf TB --- 2013-02-28 08:41:01 - /usr/sbin/config -m LINT TB --- 2013-02-28 08:41:01 - building LINT kernel TB --- 2013-02-28 08:41:01 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 08:41:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 08:41:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 08:41:01 - SRCCONF=/dev/null TB --- 2013-02-28 08:41:01 - TARGET=sparc64 TB --- 2013-02-28 08:41:01 - TARGET_ARCH=sparc64 TB --- 2013-02-28 08:41:01 - TZ=UTC TB --- 2013-02-28 08:41:01 - __MAKE_CONF=/dev/null TB --- 2013-02-28 08:41:01 - cd /src TB --- 2013-02-28 08:41:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 08:41:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 08:43:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 08:43:41 - ERROR: failed to build LINT kernel TB --- 2013-02-28 08:43:41 - 2116.63 user 367.61 system 2501.23 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 08:44:19 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31AE8AFA; Thu, 28 Feb 2013 08:44:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id DFF0414BB; Thu, 28 Feb 2013 08:44:18 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r1S8iI3X018728; Thu, 28 Feb 2013 08:44:18 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r1S8iIJH018727; Thu, 28 Feb 2013 08:44:18 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 08:44:18 GMT Message-Id: <201302280844.r1S8iIJH018727@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:44:19 -0000 TB --- 2013-02-28 08:00:35 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-02-28 08:00:35 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 08:00:35 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2013-02-28 08:00:35 - cleaning the object tree TB --- 2013-02-28 08:00:53 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-02-28 08:00:53 - cd /tinderbox/RELENG_8/powerpc/powerpc TB --- 2013-02-28 08:00:53 - /usr/local/bin/svn cleanup /src TB --- 2013-02-28 08:01:00 - /usr/local/bin/svn update /src TB --- 2013-02-28 08:01:05 - building world TB --- 2013-02-28 08:01:05 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 08:01:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 08:01:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 08:01:05 - SRCCONF=/dev/null TB --- 2013-02-28 08:01:05 - TARGET=powerpc TB --- 2013-02-28 08:01:05 - TARGET_ARCH=powerpc TB --- 2013-02-28 08:01:05 - TZ=UTC TB --- 2013-02-28 08:01:05 - __MAKE_CONF=/dev/null TB --- 2013-02-28 08:01:05 - cd /src TB --- 2013-02-28 08:01:05 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 28 08:01:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 28 08:41:47 UTC 2013 TB --- 2013-02-28 08:41:47 - generating LINT kernel config TB --- 2013-02-28 08:41:47 - cd /src/sys/powerpc/conf TB --- 2013-02-28 08:41:47 - /usr/bin/make -B LINT TB --- 2013-02-28 08:41:47 - cd /src/sys/powerpc/conf TB --- 2013-02-28 08:41:47 - /usr/sbin/config -m LINT TB --- 2013-02-28 08:41:47 - building LINT kernel TB --- 2013-02-28 08:41:47 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 08:41:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 08:41:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 08:41:47 - SRCCONF=/dev/null TB --- 2013-02-28 08:41:47 - TARGET=powerpc TB --- 2013-02-28 08:41:47 - TARGET_ARCH=powerpc TB --- 2013-02-28 08:41:47 - TZ=UTC TB --- 2013-02-28 08:41:47 - __MAKE_CONF=/dev/null TB --- 2013-02-28 08:41:47 - cd /src TB --- 2013-02-28 08:41:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 28 08:41:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_setup_transmit_ring': /src/sys/dev/e1000/if_em.c:3349: warning: implicit declaration of function 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c:3349: warning: nested extern declaration of 'netmap_idx_n2k' /src/sys/dev/e1000/if_em.c: In function 'em_txeof': /src/sys/dev/e1000/if_em.c:3812: error: 'struct netmap_adapter' has no member named 'tx_si' /src/sys/dev/e1000/if_em.c: In function 'em_rxeof': /src/sys/dev/e1000/if_em.c:4424: error: 'struct netmap_adapter' has no member named 'rx_si' *** [if_em.o] Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-02-28 08:44:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 08:44:18 - ERROR: failed to build LINT kernel TB --- 2013-02-28 08:44:18 - 2222.98 user 376.10 system 2622.50 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 09:30:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E14A81C; Thu, 28 Feb 2013 09:30:19 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1251723; Thu, 28 Feb 2013 09:30:19 +0000 (UTC) Received: from chombo.houseloki.net (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 254B9E6001; Thu, 28 Feb 2013 01:30:17 -0800 (PST) Received: from [127.0.0.1] (ivo.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id E4164549; Thu, 28 Feb 2013 01:30:16 -0800 (PST) Message-ID: <512F23AC.1000003@bluerosetech.com> Date: Thu, 28 Feb 2013 01:30:20 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? References: <512EB5BD.1020803@bluerosetech.com> <20130228014635.GB70215@glenbarber.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 09:30:19 -0000 On 2013-02-27 18:23, Adrian Chadd wrote: > Hm, have you disabled that CAM target layer stuff at boot? It's likely > tying up some RAM. Disabling CTL let cc1plus get is resident size up to 167 MB, but that still wasn't enough. Building clang is simply too memory intensive. :/ To the buildbox! From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 09:41:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5949C1A; Thu, 28 Feb 2013 09:41:16 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mx1.freebsd.org (Postfix) with ESMTP id 76B2D17C7; Thu, 28 Feb 2013 09:41:16 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id o6so3123722oag.4 for ; Thu, 28 Feb 2013 01:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yqv97o3poysEMIkgiI514EEkgGFYI1IrRqN6BVv7fsw=; b=sy1/WEBAmcviyDmkk8ZZRS6K/eCAIT8kZ5vmSZdK51Sz53ZawnGczmJVcVger+XekT hTA3JseudgQT+qnuCwbPp0tNF4jNlBb1NGdIfRyFz+Ojcj+lTrpz6K4E87eOqdjdAyLU AzE2T6Tev1kxmOsfPbTP03tB9nmaf8gtVjGNZyt6mmu7sNfC8bzD+Hhk9s1WdSObnXeN C3o3AUPrNSbQD337uiu7lrant/awQgvtAluqvJBCLJ+IrBNpCTZ1jTdQ3W4UDao0rht7 dWFFOLnP6jWw1TGbDMLBXaGZeBgSSP7VOPe907hPdRMqoRdzU8j85i8fWZLgy+AQAMpi Al8g== MIME-Version: 1.0 X-Received: by 10.182.197.6 with SMTP id iq6mr4955363obc.76.1362044147460; Thu, 28 Feb 2013 01:35:47 -0800 (PST) Received: by 10.76.94.12 with HTTP; Thu, 28 Feb 2013 01:35:47 -0800 (PST) In-Reply-To: <20130228081329.GA6194@icarus.home.lan> References: <20130228081329.GA6194@icarus.home.lan> Date: Thu, 28 Feb 2013 10:35:47 +0100 Message-ID: Subject: Re: rc.d/sysctl fails to parse sysctl.conf From: Andreas Nilsson To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 09:41:17 -0000 On Thu, Feb 28, 2013 at 9:13 AM, Jeremy Chadwick wrote: > On Thu, Feb 28, 2013 at 08:45:11AM +0100, Andreas Nilsson wrote: > > On Wed, Feb 27, 2013 at 10:39 PM, Chris Rees wrote: > > > > > On 27 February 2013 21:19, Andreas Nilsson wrote: > > > > Hello, > > > > > > > > I tried to get my sound working, and long story short: rc.d/sysctl > parses > > > > sysctl.conf wrongly if there are sysctls of the form > > > > > > > > mib=val1=val2 > > > > > > > > which is what you need for sound. For reference I needed/wanted > > > > > > > > dev.hdaa.4.nid25_config=as=1,seq=15 > > > > dev.hdaa.4.nid31_config=as=1 > > > > > > > > I believe the following patch would address the incorrect parsing: > > > > > > > > --- /etc/rc.d/sysctl.old 2013-02-27 22:00:00.000000000 +0100 > > > > +++ /etc/rc.d/sysctl 2013-02-27 22:05:24.000000000 +0100 > > > > @@ -26,7 +26,7 @@ > > > > \#*|'') > > > > ;; > > > > *) > > > > - mib=${var%=*} > > > > + mib=${var%%=*} > > > > val=${var#*=} > > > > > > > > if current_value=`${SYSCTL} -n ${mib} > > > > 2>/dev/null`; then > > > > > > I think that this is the right thing to do here. > > > > > > Chris > > > > As a follow-up question: is sysctl.conf supposed to handle all valid > input > > one can give sysctl on the command line? Using the above example would > > normally be typed: > > sysctl dev.hdaa.4.nid25_config="as=1 seq=15" > > which works, but fails to work from sysctl.conf > > This has to do with how your shell parses things (quotes, etc.) versus > how shell scripts like /etc/rc.d/sysctl do. > > Assuming you read/speak sh: read /etc/rc.d/sysctl. It's not very long, > and fairly easy to follow, barring the %, %%, and # pattern modifier > parts (read sh man page for how those work). /etc/rc.d/sysctl is not a > "file parser" -- instead it relies on sh to do the work. > > Once you read the script, you'll understand how/why apostrophes, double > quotes, and spaces in /etc/sysctl.conf are a problem. "Solving" this > dilemma in sh is a pain in the ass and often involves utter nonsense > like escaping (\) every character and making exceptions; folks who have > written extensive shell scripts will know what I mean when I use the > term "quoting hell". > > That said, here's the general guideline: your /etc/sysctl.conf should > not contain quotes or double-quotes or spaces after the assignment (=), > generally speaking. If there is a sysctl MIB that actually > ***requires*** spaces in its value, then whoever coded their driver/bit > that way should be taken out back and flogged. Hard. This is why you > probably see Andreas using a comma-delimited model (and if that works, > fantastic+great!). > > That said: you can get spaces to work in /etc/sysctl.conf by escaping > them, i.e.: > > some.mib=foo\ bar > > You might be able to escape some types of quotes, but this gets into > "quoting hell" like I said above. Don't bother. As I said, apostrophes > (') and double-quotes (") and spaces (" "), will cause problems, and if > you read the script it'll become apparent why. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > Yes, the parsing hell is not a nice place to be in. I found that easiest solution was to split the config into separate lines like dev.hdaa.4.nid25_config=as=1 dev.hdaa.4.nid25_config=seq=15 dev.hdaa.4.nid31_config=as=1 Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 14:12:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0AF0121E; Thu, 28 Feb 2013 14:12:19 +0000 (UTC) (envelope-from prvs=1771c2725a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA4A7A7; Thu, 28 Feb 2013 14:12:18 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002450264.msg; Thu, 28 Feb 2013 14:12:11 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 28 Feb 2013 14:12:11 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1771c2725a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <5FB0404788D04ABC814D11A67B536304@multiplay.co.uk> From: "Steven Hartland" To: "rihad" , "John Baldwin" References: <512CFF90.8080806@mail.ru> <201302261548.56253.jhb@freebsd.org> <512DA073.9090908@mail.ru> <201302271159.13424.jhb@freebsd.org> <512EECD4.5080600@mail.ru> Subject: Re: mfi timeouts Date: Thu, 28 Feb 2013 14:12:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 14:12:19 -0000 ----- Original Message ----- From: "rihad" To: "John Baldwin" Cc: ; Sent: Thursday, February 28, 2013 5:36 AM Subject: Re: mfi timeouts > On 02/27/2013 08:59 PM, John Baldwin wrote: >> On Wednesday, February 27, 2013 12:58:11 am rihad wrote: >>> Now about this part taken from here >>> http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html >>> > By issuing a dummy read operation (thus forcing a flush of data >>> buffers), this issue is largely averted. >>> >>> Does this mean that battery-backed cache (BBU) is effectively rendered >>> useless, as all write operations are forced on to the disk platters on >>> every interrupt? >> No, this is a very different level. This is forcing pending PCI DMA >> transactions on the PCI bus to flush by doing a read, not forcing I/O >> buffers to be flushed to disk. >> > Thanks for clarifying. > > After applying the "dummy read" patch mfi timeouts don't appear in dmesg > output any more, but i/o stalls still occurred 2-3 times during periods > of high activity, for no more than 10-20 seconds. I guess the only way > to fix that is to choose another hardware RAID implementation, or try > Steven Hartland's patch? Does 8.3 or 9.1 include more fixes in this > area, is upgrading recommended? 8.3 and 9.1 are way behind head and I'm not aware of any significant changes to them which may help you there rihad. I would recommend using mfi from HEAD even if you stick with 8.3 or 9.1 as a base, it shouldn't require much work to back port, just avoid the busdma changes. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 14:16:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F010370 for ; Thu, 28 Feb 2013 14:16:07 +0000 (UTC) (envelope-from themartininf@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 740C87D5 for ; Thu, 28 Feb 2013 14:16:07 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UB4HG-0004HO-HI for freebsd-stable@freebsd.org; Thu, 28 Feb 2013 06:16:06 -0800 Date: Thu, 28 Feb 2013 06:16:06 -0800 (PST) From: idexbsd To: freebsd-stable@freebsd.org Message-ID: <1362060966523-5791346.post@n5.nabble.com> In-Reply-To: <1362026111303-5791173.post@n5.nabble.com> References: <6eb82e0711060722g2a7876ccrd3eaf8912f5e84fa@mail.gmail.com> <1362026111303-5791173.post@n5.nabble.com> Subject: Re: IBM xSeries 336 dual Xeon hangs on boot when APIC enabled MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 14:16:07 -0000 How i can set raid1 with this bios to work with ide or ahci? Is this possible? -- View this message in context: http://freebsd.1045724.n5.nabble.com/IBM-xSeries-336-dual-Xeon-hangs-on-boot-when-APIC-enabled-tp3941669p5791346.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 14:43:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 389C8846 for ; Thu, 28 Feb 2013 14:43:27 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0A17D8E4 for ; Thu, 28 Feb 2013 14:43:26 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id i10so3759082oag.0 for ; Thu, 28 Feb 2013 06:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=brmNSCXSyZ+U1/ddNyzPMS1W30LHSf0TqS3ZhSvBhzs=; b=JlNfdSvfYP9ODj85vaVB7rWKXz9+F9u3i2yjJYLwit+xnxyLNa7JyS6Q1/TBN2r/Hj G4WaERaUxNjpY/la47kyshiX0zJH7WfJdZrcjdosHiTtqulvTP0fzqybHghJf3SnyB+l Y5qbWfQr4uLv04HAiRDZqF0u2aQDgGKc1DUKRwWg51C/vylW7zHGP8hY4nGW28bfy42s gq0p3kW8rH7Jwcjlr/oHwt6mwGEpGkUI7JMM3u6TYdvgJtc5KcYimR8uCswC4/UjKkGf XRdMUL/akqciC2xYgqZ7ekFzLrbHUn3swFb1tkKR+t4+5VvcwLfybPNiEi7zGVu1QHez /mCw== MIME-Version: 1.0 X-Received: by 10.182.245.109 with SMTP id xn13mr5751064obc.46.1362062606197; Thu, 28 Feb 2013 06:43:26 -0800 (PST) Received: by 10.76.109.236 with HTTP; Thu, 28 Feb 2013 06:43:25 -0800 (PST) In-Reply-To: <512EB5BD.1020803@bluerosetech.com> References: <512EB5BD.1020803@bluerosetech.com> Date: Thu, 28 Feb 2013 09:43:25 -0500 Message-ID: Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? From: Ryan Stone To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 14:43:27 -0000 On Wed, Feb 27, 2013 at 8:41 PM, Darren Pilgrim < list_freebsd@bluerosetech.com> wrote: > 2. If I crossbuild for this machine, can I get away with doing buildworld > on a buildbox, ship the obj tree, and do installworld and mergemaster on > the VM? It's been a few enternities since I did a cross build and back > then it was crossbuilding releases. > It's possible with a caveat: in my experience both the object tree and the source tree have to have *exactly* the same path on the build host and the destination. You can't (for example) build with MAKEOBJDIRPREFIX set to something, then copy src to /usr/src and obj to /usr/obj on the destination and have installworld work. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 17:48:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A94771E9 for ; Thu, 28 Feb 2013 17:48:22 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [199.48.134.58]) by mx1.freebsd.org (Postfix) with ESMTP id 8D28E6BB for ; Thu, 28 Feb 2013 17:48:22 +0000 (UTC) Received: from chombo.houseloki.net (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by rush.bluerosetech.com (Postfix) with ESMTPSA id E9A0411437; Thu, 28 Feb 2013 09:48:20 -0800 (PST) Received: from [127.0.0.1] (ivo.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id 7E3315D0; Thu, 28 Feb 2013 09:48:19 -0800 (PST) Message-ID: <512F9867.5020100@bluerosetech.com> Date: Thu, 28 Feb 2013 09:48:23 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ryan Stone Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? References: <512EB5BD.1020803@bluerosetech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 17:48:22 -0000 On 2013-02-28 06:43, Ryan Stone wrote: > It's possible with a caveat: in my experience both the object tree and > the source tree have to have *exactly* the same path on the build host > and the destination. You can't (for example) build with > MAKEOBJDIRPREFIX set to something, then copy src to /usr/src and obj to > /usr/obj on the destination and have installworld work. Why couldn't I just also specify MAKEOBJDIRPREFIX on the destination machine? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 18:09:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1CD2AB9F for ; Thu, 28 Feb 2013 18:09:25 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id E15C27F4 for ; Thu, 28 Feb 2013 18:09:24 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so4164822oag.30 for ; Thu, 28 Feb 2013 10:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3ADQF71GNzEzj5wkxp59sBL8l9rFeDDUXpS3fSlMT3c=; b=cUeRK7b8oHTEbKSQq7XjinIMRCV+6UMcQHBnFL34ooe7dv71dSXiP6Yctsqe3oIv8B lKLPs2GffeJfEvcn+o3wgUsWwzFz2pDxTwghXgwL1LO3dnG87QEoZULHdU73KJ9DfcZ0 ypOX4/zxyH2ibg7StVFdsxdQ85tsxCCaiYun9hW/Jl54pd+yPOOXOLSImvV/kY3TPrTW 3H/4Z7YNMqp+exBhh7PTcspZ4Gt8644dppo2+ZJ1Cll2eLV6BjkN9wsfaxz0Qcx0Kg+R 3yD8TpC7dTaiQkaPb1y1X50XVm3Z+zECNQDuU9EECyEkRby+CrsH6W8YVeQ7aB51Z+P1 hFNg== MIME-Version: 1.0 X-Received: by 10.60.31.225 with SMTP id d1mr6153971oei.120.1362074958710; Thu, 28 Feb 2013 10:09:18 -0800 (PST) Received: by 10.76.109.236 with HTTP; Thu, 28 Feb 2013 10:09:18 -0800 (PST) In-Reply-To: <512F9867.5020100@bluerosetech.com> References: <512EB5BD.1020803@bluerosetech.com> <512F9867.5020100@bluerosetech.com> Date: Thu, 28 Feb 2013 13:09:18 -0500 Message-ID: Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? From: Ryan Stone To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 18:09:25 -0000 On Thu, Feb 28, 2013 at 12:48 PM, Darren Pilgrim < list_freebsd@bluerosetech.com> wrote: > On 2013-02-28 06:43, Ryan Stone wrote: > >> It's possible with a caveat: in my experience both the object tree and >> the source tree have to have *exactly* the same path on the build host >> and the destination. You can't (for example) build with >> MAKEOBJDIRPREFIX set to something, then copy src to /usr/src and obj to >> /usr/obj on the destination and have installworld work. >> > > Why couldn't I just also specify MAKEOBJDIRPREFIX on the destination > machine? > You can, but it has to be the same path on both machines. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 28 19:05:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC873F95; Thu, 28 Feb 2013 19:05:24 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from fallback7.mail.ru (fallback7.mail.ru [94.100.176.135]) by mx1.freebsd.org (Postfix) with ESMTP id 61829CEF; Thu, 28 Feb 2013 19:05:24 +0000 (UTC) Received: from smtp10.mail.ru (smtp10.mail.ru [94.100.176.152]) by fallback7.mail.ru (mPOP.Fallback_MX) with ESMTP id 09932C25C2FB; Thu, 28 Feb 2013 23:05:22 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=X5KuU5K7He90rfht3RzpVc93SNpCcCI6CVzgXrzCrLo=; b=XNoRjeF8yOL1js9uqbkIhBJjBRy0WdIMYYPjBj823D2kK3FCHIz4W5gt59OMHj9vxGIs/KiBAAJpcmfeJJo/Mpuv5VBKm2BIAMNZROyeuC+Sv7+PX287Vf+XZw1B06w0; Received: from [217.25.27.27] (port=43207) by smtp10.mail.ru with esmtpa (envelope-from ) id 1UB8n4-0006MM-Ms; Thu, 28 Feb 2013 23:05:14 +0400 Message-ID: <512FAA68.5040206@mail.ru> Date: Thu, 28 Feb 2013 23:05:12 +0400 From: rihad User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: mfi timeouts References: <512CFF90.8080806@mail.ru> <201302261548.56253.jhb@freebsd.org> <512DA073.9090908@mail.ru> <201302271159.13424.jhb@freebsd.org> <512EECD4.5080600@mail.ru> In-Reply-To: <512EECD4.5080600@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Feb 2013 19:05:24 -0000 On 02/28/2013 09:36 AM, rihad wrote: > On 02/27/2013 08:59 PM, John Baldwin wrote: >> On Wednesday, February 27, 2013 12:58:11 am rihad wrote: >>> Now about this part taken from here >>> http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html >>> > By issuing a dummy read operation (thus forcing a flush of data >>> buffers), this issue is largely averted. >>> >>> Does this mean that battery-backed cache (BBU) is effectively rendered >>> useless, as all write operations are forced on to the disk platters on >>> every interrupt? >> No, this is a very different level. This is forcing pending PCI DMA >> transactions on the PCI bus to flush by doing a read, not forcing I/O >> buffers to be flushed to disk. >> > Thanks for clarifying. > > After applying the "dummy read" patch mfi timeouts don't appear in > dmesg output any more, but i/o stalls still occurred 2-3 times during > periods of high activity, for no more than 10-20 seconds. I guess the > only way to fix that is to choose another hardware RAID > implementation, or try Steven Hartland's patch? Does 8.3 or 9.1 > include more fixes in this area, is upgrading recommended? Oops, still same errors occurring even after kernel rebuild... I/O stalled for around 100 seconds as per application logs... I wonder why the patch didn't help? :( mfi0: COMMAND 0xffffff80010ccda0 TIMEOUT AFTER 59 SECONDS mfi0: COMMAND 0xffffff80010ccaf8 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cc520 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010ca6d8 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cc410 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010ca7e8 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010caa08 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cbfd0 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cc0e0 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010c9880 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cca70 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010c94c8 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cae48 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010ccb80 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010ca320 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010c9990 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cb178 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cac28 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010ca8f8 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cd0d0 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010c9f68 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010c9440 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010ca430 TIMEOUT AFTER 57 SECONDS mfi0: COMMAND 0xffffff80010cc058 TIMEOUT AFTER 56 SECONDS mfi0: COMMAND 0xffffff80010cb288 TIMEOUT AFTER 52 SECONDS mfi0: COMMAND 0xffffff80010cb6c8 TIMEOUT AFTER 52 SECONDS mfi0: COMMAND 0xffffff80010cbc18 TIMEOUT AFTER 51 SECONDS mfi0: COMMAND 0xffffff80010cbdb0 TIMEOUT AFTER 51 SECONDS mfi0: COMMAND 0xffffff80010c97f8 TIMEOUT AFTER 47 SECONDS mfi0: COMMAND 0xffffff80010ccc90 TIMEOUT AFTER 41 SECONDS mfi0: COMMAND 0xffffff80010cd048 TIMEOUT AFTER 37 SECONDS From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 04:08:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7915118E for ; Fri, 1 Mar 2013 04:08:11 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2A32B62C for ; Fri, 1 Mar 2013 04:08:10 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id 5F06B11A44C2 for ; Fri, 1 Mar 2013 00:08:03 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 35314-09 for ; Fri, 1 Mar 2013 04:08:02 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 6D6E711A44C1 for ; Fri, 1 Mar 2013 00:08:01 -0400 (AST) From: Marc Fournier Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: bce0: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state = 0x00004006) Message-Id: Date: Thu, 28 Feb 2013 20:07:59 -0800 To: "freebsd-stable@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 04:08:11 -0000 Hi =85 Running a kernel updated on the 24th, I just experienced a total hang = of the ethernet =85 the funny thing is that when I went to the remote = console, the network suddenly came up on its own, after being down for = about 2 hours ... I had originally thought it had to do with VirtualBox, since up until = now, the only boxes I'd see exhibiting this were running a VirtualBox = VPS, but this server doesn't have one running =85=20 Has anyone seem this before? =20 The odd thing is that the bce driver code hasn't been modified since Nov = 17th, 2012, according to the FBSDID tag in if_bce.c =85 so its not a = change to the driver itself =85 I was having some odd issues with another server that has VirtualBox, = where similar would happen =85 I reverted back to code around Feb 5th, = and it seemed to have gone away =85 am trying to see if I can narrow it = down to a specific date, but maybe the error message has more meaning = for someone else =85 ? Thx =85 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:02 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DC3B64EE; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id AC793A30; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18W016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215UaBt030355; Fri, 1 Mar 2013 05:30:36 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:30:36 GMT Message-Id: <201303010530.r215UaBt030355@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:02 -0000 TB --- 2013-03-01 05:22:20 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:22:20 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:22:20 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-03-01 05:22:20 - cleaning the object tree TB --- 2013-03-01 05:22:20 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:22:20 - cd /tinderbox/RELENG_9/i386/i386 TB --- 2013-03-01 05:22:20 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:23:06 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:23:36 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:23:36 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:24:06 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:24:36 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:24:36 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:25:36 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:26:06 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:26:06 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:27:36 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:28:06 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:28:06 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:30:06 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:30:36 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:30:36 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:30:36 - 4.06 user 5.01 system 496.31 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E14964EF; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B1001A31; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18U016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215lj31084901; Fri, 1 Mar 2013 05:47:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:47:45 GMT Message-Id: <201303010547.r215lj31084901@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:39:25 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:39:25 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:39:25 - starting RELENG_9 tinderbox run for mips/mips TB --- 2013-03-01 05:39:25 - cleaning the object tree TB --- 2013-03-01 05:39:25 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:39:25 - cd /tinderbox/RELENG_9/mips/mips TB --- 2013-03-01 05:39:25 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:40:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:40:56 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:40:56 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:41:26 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:41:45 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:41:45 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:42:45 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:43:15 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:43:15 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:44:45 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:45:15 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:45:15 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:47:15 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:47:45 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:47:45 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:47:45 - 4.24 user 4.82 system 499.84 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E62F24F0; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B55E4A32; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18a016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215uPP8025244; Fri, 1 Mar 2013 05:56:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:56:25 GMT Message-Id: <201303010556.r215uPP8025244@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:48:30 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:48:30 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:48:30 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2013-03-01 05:48:30 - cleaning the object tree TB --- 2013-03-01 05:48:30 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:48:30 - cd /tinderbox/RELENG_9/sparc64/sparc64 TB --- 2013-03-01 05:48:30 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:49:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:49:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:49:30 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:50:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:50:25 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:50:25 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:51:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:51:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:51:55 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:53:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:53:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:53:55 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:55:55 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:56:25 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:56:25 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:56:25 - 3.85 user 5.04 system 475.03 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF9B74F1; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B967AA33; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18Y016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215cebR058704; Fri, 1 Mar 2013 05:38:40 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:38:40 GMT Message-Id: <201303010538.r215cebR058704@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:30:36 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:30:36 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:30:36 - starting RELENG_9 tinderbox run for i386/pc98 TB --- 2013-03-01 05:30:36 - cleaning the object tree TB --- 2013-03-01 05:30:36 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:30:36 - cd /tinderbox/RELENG_9/i386/pc98 TB --- 2013-03-01 05:30:36 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:31:11 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:31:41 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:31:41 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:32:11 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:32:40 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:32:40 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:33:40 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:34:10 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:34:10 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:35:40 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:36:10 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:36:10 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:38:10 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:38:40 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:38:40 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:38:40 - 4.18 user 4.94 system 483.71 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F010A4F2; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id BDCB6A34; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18g016166; Fri, 1 Mar 2013 06:30:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215LZoe096729; Fri, 1 Mar 2013 05:21:35 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:21:35 GMT Message-Id: <201303010521.r215LZoe096729@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:13:00 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:13:00 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:13:00 - starting RELENG_9 tinderbox run for amd64/amd64 TB --- 2013-03-01 05:13:00 - cleaning the object tree TB --- 2013-03-01 05:13:00 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:13:00 - cd /tinderbox/RELENG_9/amd64/amd64 TB --- 2013-03-01 05:13:00 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:14:05 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:14:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:14:35 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:15:05 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:15:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:15:35 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:16:35 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:17:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:17:05 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:18:35 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:19:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:19:05 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:21:05 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:21:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:21:35 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:21:35 - 4.04 user 4.93 system 514.39 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00EF24F3; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id C24A6A36; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18c016166; Fri, 1 Mar 2013 06:30:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215mUw4091068; Fri, 1 Mar 2013 05:48:30 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:48:30 GMT Message-Id: <201303010548.r215mUw4091068@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:40:10 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:40:10 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:40:10 - starting RELENG_9 tinderbox run for powerpc/powerpc TB --- 2013-03-01 05:40:10 - cleaning the object tree TB --- 2013-03-01 05:40:10 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:40:10 - cd /tinderbox/RELENG_9/powerpc/powerpc TB --- 2013-03-01 05:40:10 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:41:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:41:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:41:30 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:42:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:42:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:42:30 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:43:30 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:44:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:44:00 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:45:30 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:46:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:46:00 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:48:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:48:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:48:30 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:48:30 - 4.29 user 5.02 system 499.77 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 02BB94F4; Fri, 1 Mar 2013 06:30:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id C6240A37; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18e016166; Fri, 1 Mar 2013 06:30:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215qUtv012712; Fri, 1 Mar 2013 05:52:30 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:52:30 GMT Message-Id: <201303010552.r215qUtv012712@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:44:07 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:44:07 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:44:07 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2013-03-01 05:44:07 - cleaning the object tree TB --- 2013-03-01 05:44:07 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:44:07 - cd /tinderbox/RELENG_9/powerpc64/powerpc TB --- 2013-03-01 05:44:07 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:45:12 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:45:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:45:30 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:46:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:46:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:46:30 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:47:30 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:48:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:48:00 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:49:30 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:50:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:50:00 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:52:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:52:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:52:30 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:52:30 - 3.88 user 4.38 system 502.57 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 113A34F5; Fri, 1 Mar 2013 06:30:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id D4102A38; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18i016166; Fri, 1 Mar 2013 06:30:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215L1TO094762; Fri, 1 Mar 2013 05:21:01 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:21:01 GMT Message-Id: <201303010521.r215L1TO094762@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9_1 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:12:33 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:12:33 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:12:33 - starting RELENG_9_1 tinderbox run for sparc64/sparc64 TB --- 2013-03-01 05:12:33 - cleaning the object tree TB --- 2013-03-01 05:12:33 - checking out /src from svn://svn.freebsd.org/base/releng/9.1 TB --- 2013-03-01 05:12:33 - cd /tinderbox/RELENG_9_1/sparc64/sparc64 TB --- 2013-03-01 05:12:33 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:13:32 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:14:02 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:14:02 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:14:32 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:15:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:15:00 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:16:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:16:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:16:30 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:18:00 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:18:30 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:18:30 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:20:30 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:21:00 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:21:00 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:21:00 - 4.07 user 4.80 system 506.52 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 163B84F8; Fri, 1 Mar 2013 06:30:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id DB5FBA39; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18S016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215dPHe063517; Fri, 1 Mar 2013 05:39:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:39:25 GMT Message-Id: <201303010539.r215dPHe063517@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:31:21 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:31:21 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:31:21 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-03-01 05:31:21 - cleaning the object tree TB --- 2013-03-01 05:31:21 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:31:21 - cd /tinderbox/RELENG_9/ia64/ia64 TB --- 2013-03-01 05:31:21 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:31:55 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:32:25 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:32:25 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:32:55 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:33:25 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:33:25 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:34:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:34:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:34:55 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:36:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:36:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:36:55 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:38:55 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:39:25 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:39:25 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:39:25 - 4.16 user 4.88 system 483.56 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 06:30:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1B9044F9; Fri, 1 Mar 2013 06:30:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id DF2EDA3A; Fri, 1 Mar 2013 06:30:02 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r216U18Q016166; Fri, 1 Mar 2013 06:30:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r215TpLv028723; Fri, 1 Mar 2013 05:29:51 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Mar 2013 05:29:51 GMT Message-Id: <201303010529.r215TpLv028723@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:30:03 -0000 TB --- 2013-03-01 05:21:46 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-01 05:21:46 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-01 05:21:46 - starting RELENG_9 tinderbox run for arm/arm TB --- 2013-03-01 05:21:46 - cleaning the object tree TB --- 2013-03-01 05:21:46 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-01 05:21:46 - cd /tinderbox/RELENG_9/arm/arm TB --- 2013-03-01 05:21:46 - /usr/local/bin/svn cleanup /src TB --- 2013-03-01 05:22:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:22:55 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:22:55 - WARNING: sleeping 30 s and retrying... TB --- 2013-03-01 05:23:25 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:23:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:23:51 - WARNING: sleeping 60 s and retrying... TB --- 2013-03-01 05:24:51 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:25:21 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:25:21 - WARNING: sleeping 90 s and retrying... TB --- 2013-03-01 05:26:51 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:27:21 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:27:21 - WARNING: sleeping 120 s and retrying... TB --- 2013-03-01 05:29:21 - /usr/local/bin/svn update /src TB --- 2013-03-01 05:29:51 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-03-01 05:29:51 - ERROR: unable to check out the source tree TB --- 2013-03-01 05:29:51 - 3.95 user 4.98 system 484.98 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 07:24:22 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3BB09C9; Fri, 1 Mar 2013 07:24:21 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9D736D15; Fri, 1 Mar 2013 07:24:21 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id F239789DF; Fri, 1 Mar 2013 07:24:19 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AC3EF9C85; Fri, 1 Mar 2013 08:24:19 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: FreeBSD Tinderbox Subject: Re: [releng_9 tinderbox] failure on amd64/amd64 References: <201303010521.r215LZoe096729@freebsd-stable.sentex.ca> Date: Fri, 01 Mar 2013 08:24:18 +0100 In-Reply-To: <201303010521.r215LZoe096729@freebsd-stable.sentex.ca> (FreeBSD Tinderbox's message of "Fri, 1 Mar 2013 05:21:35 GMT") Message-ID: <86fw0ftwf1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 07:24:22 -0000 FreeBSD Tinderbox writes: > TB --- 2013-03-01 05:14:35 - WARNING: /usr/local/bin/svn returned exit co= de 1=20 > TB --- 2013-03-01 05:14:35 - WARNING: sleeping 30 s and retrying... This seems to have been a transient DNS issue. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 09:54:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3747EF80 for ; Fri, 1 Mar 2013 09:54:12 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8262FF for ; Fri, 1 Mar 2013 09:54:11 +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.69) (envelope-from ) id 1UBMPh-0004rP-6c; Fri, 01 Mar 2013 10:38:02 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBMPh-0003Lg-62; Fri, 01 Mar 2013 10:38:01 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Panic at shutdown (acpi related) References: <51127767.1030007@gmail.com> <2872289.1yXr0e1VeO@melon.malikania.fr> <1722921.irhDJY2y33@melon> Date: Fri, 01 Mar 2013 10:38:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <1722921.irhDJY2y33@melon> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 2d9f92a6a8fd5960702c593e69d2c65b Cc: David Demelier X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:54:12 -0000 On Sun, 24 Feb 2013 13:04:52 +0100, David Demelier wrote: > Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit : >> On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier >> >> wrote: >> > Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit : >> >> on 12/02/2013 09:57 David Demelier said the following: >> >> > Yes I have added debugging option in my kernel. I have makeoptions >> >> > DEBUG=-g in my config. Do I need more ? >> >> >> >> .symbols? >> > >> > I don't understand what you are saying, I have >> > /boot/kernel/kernel.symbols. >> > Please tell me what I'm doing wrong. I've just read and done the steps >> > written >> > there : >> > >> > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- >> > gdb.html >> > >> > So I've run >> > >> > # cd /usr/obj/usr/src/sys/Melon >> > # kgdb kernel.debug /var/crash/vmcore.0 >> >> Why not something like kgdb /boot/kernel/kernel.symbols >> /var/crash/vmcore.0? >> That looks like what the manual page of kgdb seems to suggest. >> >> Regards, >> Ronald. >> >> > and that's the only trace I get using bt full : >> > >> > 229 #define IS_BSP() (PCPU_GET(cpuid) == 0) >> > (kgdb) bt full >> > #0 doadump (textdump=) at pcpu.h:229 >> > No locals. >> > #1 0x0000000000000000 in ?? () >> > No symbol table info available. >> > > > I have that, in fact I was using bt full instead of short bt : > > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > #1 0x0000000000000004 in ?? () > #2 0xffffffff805146b6 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:448 > #3 0xffffffff80514b79 in panic (fmt=0x1
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #4 0xffffffff8071e919 in trap_fatal (frame=0xc, eva=Variable "eva" is > not > available. > ) at /usr/src/sys/amd64/amd64/trap.c:857 > #5 0xffffffff8071eca4 in trap_pfault (frame=0xffffff80d63db5d0, > usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:773 > #6 0xffffffff8071f09b in trap (frame=0xffffff80d63db5d0) at > /usr/src/sys/amd64/amd64/trap.c:456 > #7 0xffffffff8070993f in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:228 > #8 0xffffffff802ddbf5 in AcpiOsAcquireObject (Cache=0xfffffe00015de400) > at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > #9 0xffffffff802e27c1 in AcpiUtAllocateObjectDescDbg > (ModuleName=0xffffffff80795110 "dsutils", > LineNumber=703, ComponentId=Variable "ComponentId" is not available. > ) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 > #10 0xffffffff802e2972 in AcpiUtCreateInternalObjectDbg > (ModuleName=0xffffffff80795110 "dsutils", > LineNumber=703, ComponentId=64, Type=1) > at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:112 > #11 0xffffffff802b32ea in AcpiDsCreateOperand > (WalkState=0xfffffe000380fc00, > Arg=0xfffffe00017d39c0, > ArgIndex=0) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 > #12 0xffffffff802b3686 in AcpiDsCreateOperands > (WalkState=0xfffffe000380fc00, > FirstArg=0xfffffe00017d39c0) at > /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798 > #13 0xffffffff802b4323 in AcpiDsExecEndOp (WalkState=0xfffffe000380fc00) > at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:449 > #14 0xffffffff802d55e9 in AcpiPsParseLoop (WalkState=0xfffffe000380fc00) > at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 > #15 0xffffffff802d6a5b in AcpiPsParseAml (WalkState=0xfffffe000380fc00) > at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 > #16 0xffffffff802d7ad7 in AcpiPsExecuteMethod (Info=0xfffffe00411b9500) > at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 > #17 0xffffffff802ce3af in AcpiNsEvaluate (Info=0xfffffe00411b9500) > at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 > #18 0xffffffff802d3567 in AcpiEvaluateObject (Handle=0xfffffe00017d6d40, > Pathname=0xffffffff807b2e9b "_TMP", ExternalParams=0x0, > ReturnBuffer=0xffffff80d63dba50) > at /usr/src/sys/contrib/dev/acpica/namespace/nsxfeval.c:289 > #19 0xffffffff8031ca84 in acpi_GetInteger (handle=0xfffffe00017d6d40, > path=0xffffffff807b2e9b "_TMP", number=0xffffff80d63dbab4) at > /usr/src/sys/dev/acpica/acpi.c:2204 > #20 0xffffffff80331756 in acpi_tz_get_temperature (sc=0xfffffe0001a2fa00) > at /usr/src/sys/dev/acpica/acpi_thermal.c:462 > #21 0xffffffff803329d6 in acpi_tz_monitor (Context=0xfffffe0001a2fa00) > at /usr/src/sys/dev/acpica/acpi_thermal.c:497 > #22 0xffffffff80332f92 in acpi_tz_thread (arg=Variable "arg" is not > available. > ) at /usr/src/sys/dev/acpica/acpi_thermal.c:864 > #23 0xffffffff804e7a3d in fork_exit (callout=0xffffffff80332e50 > , arg=0x0, > frame=0xffffff80d63dbc00) at /usr/src/sys/kern/kern_fork.c:992 > #24 0xffffffff80709dfe in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:602 > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000001 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000000000 in ?? () > #43 0x0000000000000000 in ?? () > #44 0x0000000000000000 in ?? () > #45 0x0000000000000000 in ?? () > #46 0x0000000000000000 in ?? () > #47 0x0000000000000000 in ?? () > #48 0x0000000000000000 in ?? () > #49 0xffffffff80b5b1c0 in affinity () > #50 0x0000000000000000 in ?? () > #51 0xfffffe0001a5e8b0 in ?? () > #52 0xfffffe0001a5e470 in ?? () > #53 0x0000000000000000 in ?? () > #54 0xffffff80d63dba08 in ?? () > #55 0xfffffe00016db8e0 in ?? () > #56 0xffffffff8053ccf9 in sched_switch (td=0xffffffff80332e50, newtd=0x0, > flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1921 > #57 0x0000000000000000 in ?? () > #58 0x0000000000000000 in ?? () > #59 0x0000000000000000 in ?? () > #60 0x0000000000000000 in ?? () > #61 0x0000000000000000 in ?? () > #62 0x0000000000000000 in ?? () > #63 0x0000000000000001 in ?? () > #64 0x0000000000000000 in ?? () > #65 0x0000000000000000 in ?? () > #66 0x0000000000000000 in ?? () > #67 0xffffff80d63dbdc0 in ?? () > #68 0x0000000000000000 in ?? () > #69 0x0000000000000000 in ?? () > #70 0x0000000000000000 in ?? () > #71 0x0000000000000000 in ?? () > #72 0x0000000000000000 in ?? () > #73 0x0000000000000000 in ?? () > #74 0x0000000000000000 in ?? () > #75 0x0000000000000000 in ?? () > #76 0x0000000000000000 in ?? () > #77 0x0000000000000000 in ?? () > #78 0x0000000000000000 in ?? () > #79 0x0000000000000000 in ?? () > #80 0x0000000000000000 in ?? () > #81 0x0000000000000000 in ?? () > #82 0x0000000000000000 in ?? () > #83 0x0000000000000000 in ?? () > #84 0x0000000000000000 in ?? () > #85 0x0000000000000000 in ?? () > #86 0x0000000000000000 in ?? () > #87 0x0000000000000000 in ?? () > #88 0x0000000000000000 in ?? () > #89 0x0000000000000000 in ?? () > #90 0x0000000000000000 in ?? () > #91 0x0000000000000000 in ?? () > #92 0x0000000000000000 in ?? () > #93 0x0000000000000000 in ?? () > #94 0x0000000000000000 in ?? () > #95 0x0000000000000000 in ?? () > #96 0x0000000000000000 in ?? () > #97 0x0000000000000000 in ?? () > #98 0x0000000000000000 in ?? () > #99 0x0000000000000000 in ?? () > #100 0x0000000000000000 in ?? () > #101 0x0000000000000000 in ?? () > #102 0x0000000000000000 in ?? () > #103 0x0000000000000000 in ?? () > #104 0x0000000000000000 in ?? () > #105 0x0000000000000000 in ?? () > #106 0x0000000000000000 in ?? () > #107 0x0000000000000000 in ?? () > #108 0x0000000000000000 in ?? () > #109 0x0000000000000000 in ?? () > #110 0x0000000000000000 in ?? () > #111 0x0000000000000000 in ?? () > #112 0x0000000000000000 in ?? () > #113 0x0000000000000000 in ?? () > #114 0x0000000000000000 in ?? () > #115 0x0000000000000000 in ?? () > #116 0x0000000000000000 in ?? () > #117 0x0000000000000000 in ?? () > #118 0x0000000000000000 in ?? () > #119 0x0000000000000000 in ?? () > #120 0x0000000000000000 in ?? () > #121 0x0000000000000000 in ?? () > #122 0x0000000000000000 in ?? () > #123 0x0000000000000000 in ?? () > #124 0x0000000000000000 in ?? () > #125 0x0000000000000000 in ?? () > #126 0x0000000000000000 in ?? () > #127 0x0000000000000000 in ?? () > #128 0x0000000000000000 in ?? () > #129 0x0000000000000000 in ?? () > #130 0x0000000000000000 in ?? () > #131 0x0000000000000000 in ?? () > #132 0x0000000000000000 in ?? () > #133 0x0000000000000000 in ?? () > #134 0x0000000000000003 in ?? () > #135 0x0000000000000000 in ?? () > #136 0x0000000000000000 in ?? () > #137 0x0000000000000000 in ?? () > #138 0x0000000000000000 in ?? () > #139 0x0000000000000000 in ?? () > #140 0x0000000000000000 in ?? () > #141 0x0000000000000000 in ?? () > Cannot access memory at address 0xffffff80d63dc000 > Hi, I am not familiar with this acpi stuff so I hope somebody else can help you. Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 14:25:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D3955A8 for ; Fri, 1 Mar 2013 14:25:08 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1D38DFA1 for ; Fri, 1 Mar 2013 14:25:07 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r21EOwmp048051 for ; Fri, 1 Mar 2013 08:24:59 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Mar 1 08:24:59 2013 Message-ID: <5130BA35.5060809@denninger.net> Date: Fri, 01 Mar 2013 08:24:53 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Musings on ZFS Backup strategies X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130301-0, 03/01/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 14:25:08 -0000 Dabbling with ZFS now, and giving some thought to how to handle backup strategies. ZFS' snapshot capabilities have forced me to re-think the way that I've handled this. Previously near-line (and offline) backup was focused on being able to handle both disasters (e.g. RAID adapter goes nuts and scribbles on the entire contents of the array), a double-disk (or worse) failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just rm -rf'd something I'd rather not!" ZFS makes snapshots very cheap, which means you can resolve the "aw crap" situation without resorting to backups at all. This turns the backup situation into a disaster recovery one. And that in turn seems to say that the ideal strategy looks more like: Take a base snapshot immediately and zfs send it to offline storage. Take an incremental at some interval (appropriate for disaster recovery) and zfs send THAT to stable storage. If I then restore the base and snapshot, I get back to where I was when the latest snapshot was taken. I don't need to keep the incremental snapshot for longer than it takes to zfs send it, so I can do: zfs snapshot pool/some-filesystem@unique-label zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label zfs destroy pool/some-filesystem@unique-label and that seems to work (and restore) just fine. Am I looking at this the right way here? Provided that the base backup and incremental are both readable, it appears that I have the disaster case covered, and the online snapshot increments and retention are easily adjusted and cover the "oops" situations without having to resort to the backups at all. This in turn means that keeping more than two incremental dumps offline has little or no value; the second merely being taken to insure that there is always at least one that has been written to completion without error to apply on top of the base. That in turn makes the backup storage requirement based only on entropy in the filesystem and not time (where the "tower of Hanoi" style dump hierarchy imposed both a time AND entropy cost on backup media.) Am I missing something here? (Yes, I know, I've been a ZFS resister.... ;-)) -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 15:06:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3F6D5D2 for ; Fri, 1 Mar 2013 15:06:10 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1D1247 for ; Fri, 1 Mar 2013 15:06:10 +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.69) (envelope-from ) id 1UBRXD-0002dq-4K; Fri, 01 Mar 2013 16:06:07 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBRXD-0006uo-1A; Fri, 01 Mar 2013 16:06:07 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, "Karl Denninger" Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> Date: Fri, 01 Mar 2013 16:06:05 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <5130BA35.5060809@denninger.net> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 9b84bad32751a42de3aa9e7877f1ca86 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:06:11 -0000 On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger wrote: > Dabbling with ZFS now, and giving some thought to how to handle backup > strategies. > > ZFS' snapshot capabilities have forced me to re-think the way that I've > handled this. Previously near-line (and offline) backup was focused on > being able to handle both disasters (e.g. RAID adapter goes nuts and > scribbles on the entire contents of the array), a double-disk (or worse) > failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just > rm -rf'd something I'd rather not!" > > ZFS makes snapshots very cheap, which means you can resolve the "aw > crap" situation without resorting to backups at all. This turns the > backup situation into a disaster recovery one. > > And that in turn seems to say that the ideal strategy looks more like: > > Take a base snapshot immediately and zfs send it to offline storage. > Take an incremental at some interval (appropriate for disaster recovery) > and zfs send THAT to stable storage. > > If I then restore the base and snapshot, I get back to where I was when > the latest snapshot was taken. I don't need to keep the incremental > snapshot for longer than it takes to zfs send it, so I can do: > > zfs snapshot pool/some-filesystem@unique-label > zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label > zfs destroy pool/some-filesystem@unique-label > > and that seems to work (and restore) just fine. > > Am I looking at this the right way here? Provided that the base backup > and incremental are both readable, it appears that I have the disaster > case covered, and the online snapshot increments and retention are > easily adjusted and cover the "oops" situations without having to resort > to the backups at all. > > This in turn means that keeping more than two incremental dumps offline > has little or no value; the second merely being taken to insure that > there is always at least one that has been written to completion without > error to apply on top of the base. That in turn makes the backup > storage requirement based only on entropy in the filesystem and not time > (where the "tower of Hanoi" style dump hierarchy imposed both a time AND > entropy cost on backup media.) > > Am I missing something here? > > (Yes, I know, I've been a ZFS resister.... ;-)) > I do the same. I only use zfs send -I (capital i) so I have all the snapshots on the backup also. That way the data survives an oops (rm -r) and a fire at the same time. :-) Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 15:29:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4C65AB18 for ; Fri, 1 Mar 2013 15:29:19 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id BF920336 for ; Fri, 1 Mar 2013 15:29:18 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fj20so3012942lab.6 for ; Fri, 01 Mar 2013 07:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=dJZ6Bdv4+FAMZmjkjUE5O6N9D+q8dAyo9GZT4bL6q5Q=; b=ycBZapWz9dt0Ynk20q26woHIfQF6S121Nx8HXlUTOBfFeTqPY/8Ttyh0P2DakI1F3S ak6zmrRA4t8zj61LKBpW60fHKSJVYzV0k5zGieUTULk8/sqlzxFYrxXXqnUDxmFfaOPY Wp/DaFYAcrcN056eiM0A6a/QchGuz2EmLGrBm2cVPbpgopWi86OzoGCiMkiIGGT7EXw+ lHLvTvxvYXQfVPvBLPG9G6Ioz5Mu+xNBiORsNpwge6qmxV2U1zgfTJ74dmd2oZopuIg5 yvlSfLy7qO6payC2JlIZIMh8RBsIGuqj07LLcMXGmsAeaR/Zgvi+RiNtBlvIfpwNxqfb CZ6g== X-Received: by 10.152.104.18 with SMTP id ga18mr9494456lab.33.1362151757658; Fri, 01 Mar 2013 07:29:17 -0800 (PST) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.59.34 with HTTP; Fri, 1 Mar 2013 07:28:57 -0800 (PST) In-Reply-To: References: <5130BA35.5060809@denninger.net> From: Royce Williams Date: Fri, 1 Mar 2013 06:28:57 -0900 X-Google-Sender-Auth: r2-5D4F6oyU2cQ7NdNkgdQRGn9E Message-ID: Subject: Re: Musings on ZFS Backup strategies To: Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable , Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:29:19 -0000 On Fri, Mar 1, 2013 at 6:06 AM, Ronald Klop wrote: > On Fri, 01 Mar 2013 15:24:53 +0100, Karl Denninger > wrote: > >> Dabbling with ZFS now, and giving some thought to how to handle backup >> strategies. >> >> ZFS' snapshot capabilities have forced me to re-think the way that I've >> handled this. Previously near-line (and offline) backup was focused on >> being able to handle both disasters (e.g. RAID adapter goes nuts and >> scribbles on the entire contents of the array), a double-disk (or worse) >> failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just >> rm -rf'd something I'd rather not!" >> >> ZFS makes snapshots very cheap, which means you can resolve the "aw >> crap" situation without resorting to backups at all. This turns the >> backup situation into a disaster recovery one. >> >> And that in turn seems to say that the ideal strategy looks more like: >> >> Take a base snapshot immediately and zfs send it to offline storage. >> Take an incremental at some interval (appropriate for disaster recovery) >> and zfs send THAT to stable storage. >> >> If I then restore the base and snapshot, I get back to where I was when >> the latest snapshot was taken. I don't need to keep the incremental >> snapshot for longer than it takes to zfs send it, so I can do: >> >> zfs snapshot pool/some-filesystem@unique-label >> zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label >> zfs destroy pool/some-filesystem@unique-label >> >> and that seems to work (and restore) just fine. >> >> Am I looking at this the right way here? Provided that the base backup >> and incremental are both readable, it appears that I have the disaster >> case covered, and the online snapshot increments and retention are >> easily adjusted and cover the "oops" situations without having to resort >> to the backups at all. >> >> This in turn means that keeping more than two incremental dumps offline >> has little or no value; the second merely being taken to insure that >> there is always at least one that has been written to completion without >> error to apply on top of the base. That in turn makes the backup >> storage requirement based only on entropy in the filesystem and not time >> (where the "tower of Hanoi" style dump hierarchy imposed both a time AND >> entropy cost on backup media.) >> >> Am I missing something here? >> >> (Yes, I know, I've been a ZFS resister.... ;-)) >> > > I do the same. I only use zfs send -I (capital i) so I have all the > snapshots on the backup also. > That way the data survives an oops (rm -r) and a fire at the same time. :-) Concur. There are "disasters" that are not obvious until some time has passed -- such as security breaches, application problems that cause quiet data corruption, etc. I do not know how a live ZFS filesystem could be manipulated by an intruder, but the possibility is there. -- Royce Williams From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 15:36:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FBCAD6B for ; Fri, 1 Mar 2013 15:36:44 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0639F3C4 for ; Fri, 1 Mar 2013 15:36:43 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.local [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id r21FaawY000860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Mar 2013 09:36:37 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 2013 09:36:36 -0600 From: dweimer To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <5130BA35.5060809@denninger.net> References: <5130BA35.5060809@denninger.net> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:36:44 -0000 On 03/01/2013 8:24 am, Karl Denninger wrote: > Dabbling with ZFS now, and giving some thought to how to handle backup > strategies. > > ZFS' snapshot capabilities have forced me to re-think the way that > I've > handled this. Previously near-line (and offline) backup was focused > on > being able to handle both disasters (e.g. RAID adapter goes nuts and > scribbles on the entire contents of the array), a double-disk (or > worse) > failure, or the obvious (e.g. fire, etc) along with the "aw crap, I > just > rm -rf'd something I'd rather not!" > > ZFS makes snapshots very cheap, which means you can resolve the "aw > crap" situation without resorting to backups at all. This turns the > backup situation into a disaster recovery one. > > And that in turn seems to say that the ideal strategy looks more like: > > Take a base snapshot immediately and zfs send it to offline storage. > Take an incremental at some interval (appropriate for disaster > recovery) > and zfs send THAT to stable storage. > > If I then restore the base and snapshot, I get back to where I was > when > the latest snapshot was taken. I don't need to keep the incremental > snapshot for longer than it takes to zfs send it, so I can do: > > zfs snapshot pool/some-filesystem@unique-label > zfs send -i pool/some-filesystem@base > pool/some-filesystem@unique-label > zfs destroy pool/some-filesystem@unique-label > > and that seems to work (and restore) just fine. > > Am I looking at this the right way here? Provided that the base > backup > and incremental are both readable, it appears that I have the disaster > case covered, and the online snapshot increments and retention are > easily adjusted and cover the "oops" situations without having to > resort > to the backups at all. > > This in turn means that keeping more than two incremental dumps > offline > has little or no value; the second merely being taken to insure that > there is always at least one that has been written to completion > without > error to apply on top of the base. That in turn makes the backup > storage requirement based only on entropy in the filesystem and not > time > (where the "tower of Hanoi" style dump hierarchy imposed both a time > AND > entropy cost on backup media.) > > Am I missing something here? > > (Yes, I know, I've been a ZFS resister.... ;-)) I briefly did something like this between two FreeNAS boxes, it seemed to work well, but my secondary Box wasn't quite up to par hardware. Combine that with the lack of necessary internet bandwidth with a second physical location in case of something really disastrous, like a tornado or fire destroying my house. I ended up just using an eSATA drive dock and Bacula, with a few external drives rotated regularly into my office at work, rather than upgrading the secondary box. If you have the secondary box that is adequate, and either offsite backups aren't a concern or you have a big enough pipe to a secondary location that houses the backup this should work. I would recommend testing your incremental snapshot rotation, I never did test a restore from anything but the most recent set of data when I was running my setup, I did however save a weeks worth of hourly snapshots on a couple of the more rapidly changing data sets. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 15:45:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFDA3E1 for ; Fri, 1 Mar 2013 15:45:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id AB37A63C for ; Fri, 1 Mar 2013 15:45:39 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r21FjbGC052161 for ; Fri, 1 Mar 2013 09:45:37 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Mar 1 09:45:37 2013 Message-ID: <5130CD1C.90709@denninger.net> Date: Fri, 01 Mar 2013 09:45:32 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> In-Reply-To: X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130301-0, 03/01/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:45:40 -0000 On 3/1/2013 9:36 AM, dweimer wrote: > On 03/01/2013 8:24 am, Karl Denninger wrote: >> Dabbling with ZFS now, and giving some thought to how to handle backup >> strategies. >> >> ZFS' snapshot capabilities have forced me to re-think the way that I've >> handled this. Previously near-line (and offline) backup was focused on >> being able to handle both disasters (e.g. RAID adapter goes nuts and >> scribbles on the entire contents of the array), a double-disk (or worse) >> failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just >> rm -rf'd something I'd rather not!" >> >> ZFS makes snapshots very cheap, which means you can resolve the "aw >> crap" situation without resorting to backups at all. This turns the >> backup situation into a disaster recovery one. >> >> And that in turn seems to say that the ideal strategy looks more like: >> >> Take a base snapshot immediately and zfs send it to offline storage. >> Take an incremental at some interval (appropriate for disaster recovery) >> and zfs send THAT to stable storage. >> >> If I then restore the base and snapshot, I get back to where I was when >> the latest snapshot was taken. I don't need to keep the incremental >> snapshot for longer than it takes to zfs send it, so I can do: >> >> zfs snapshot pool/some-filesystem@unique-label >> zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label >> zfs destroy pool/some-filesystem@unique-label >> >> and that seems to work (and restore) just fine. >> >> Am I looking at this the right way here? Provided that the base backup >> and incremental are both readable, it appears that I have the disaster >> case covered, and the online snapshot increments and retention are >> easily adjusted and cover the "oops" situations without having to resort >> to the backups at all. >> >> This in turn means that keeping more than two incremental dumps offline >> has little or no value; the second merely being taken to insure that >> there is always at least one that has been written to completion without >> error to apply on top of the base. That in turn makes the backup >> storage requirement based only on entropy in the filesystem and not time >> (where the "tower of Hanoi" style dump hierarchy imposed both a time AND >> entropy cost on backup media.) >> >> Am I missing something here? >> >> (Yes, I know, I've been a ZFS resister.... ;-)) > > I briefly did something like this between two FreeNAS boxes, it seemed > to work well, but my secondary Box wasn't quite up to par hardware. > Combine that with the lack of necessary internet bandwidth with a > second physical location in case of something really disastrous, like > a tornado or fire destroying my house. I ended up just using an eSATA > drive dock and Bacula, with a few external drives rotated regularly > into my office at work, rather than upgrading the secondary box. > > If you have the secondary box that is adequate, and either offsite > backups aren't a concern or you have a big enough pipe to a secondary > location that houses the backup this should work. > > I would recommend testing your incremental snapshot rotation, I never > did test a restore from anything but the most recent set of data when > I was running my setup, I did however save a weeks worth of hourly > snapshots on a couple of the more rapidly changing data sets. > I rotate the disaster disks out to a safe-deposit box at the bank, and they're geli-encrypted, so if stolen they're worthless to the thief (other than their cash value as a drive) and if the building goes "poof" I have the ones in the vault to recover from. There's the potential for loss up to the rotation time of course but that is the same risk I had with all UFS filesystems. I've tested the restores onto a spare box and it appears to work as expected... Thanks for the comments! -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 16:07:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1A7EADC for ; Fri, 1 Mar 2013 16:07:33 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id C014B74F for ; Fri, 1 Mar 2013 16:07:33 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so5913412oag.2 for ; Fri, 01 Mar 2013 08:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=+q54/5hafxDdgG55gYKI57DMjB6wdnd23JKh0m20v4E=; b=AWm7x7mS520s3p7wCe/+bybo+7o3tVN3NUThpfx7OWnU06Wtsslh4PzOaSWMLvrVYS enAA4OJOBlo7Te51GVQQWisOkKIb907ZqLzqE6aICfJWb0Y+3A8pZHSAbT+g0kGn9qTS h52p2p/rAQVT2ZbQ/UpXgUEvJ/HAMqHYvTcYMlWVWUeq8PRSf+NjVYVj4hZxFzOX1rd8 8DAM74VWqJWHhIysaWgCcLffES5bMnS4n3omsv36BLPjXzH7/MyRu3tmAJkomOr/LtHR rFM+d09M9vbr8KeCD57aGMmOqGucPfTRIz/Kac0o5Bj2zS9HdCdF3WlAruIjcAvBdEKh Nc0A== X-Received: by 10.182.177.101 with SMTP id cp5mr3577918obc.69.1362154052894; Fri, 01 Mar 2013 08:07:32 -0800 (PST) Received: from guysmbp.dyn.palisadesys.com ([216.81.189.10]) by mx.google.com with ESMTPS id v8sm18259536oea.4.2013.03.01.08.07.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 08:07:31 -0800 (PST) From: Guy Helmer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: New 9.x install won't autoboot Message-Id: <3470C389-FAF2-4016-8D0A-985ACDB7C562@gmail.com> Date: Fri, 1 Mar 2013 10:07:30 -0600 To: FreeBSD Stable Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:07:34 -0000 I have an odd situation: I just installed a FreeBSD 9.1 system = yesterday, and it always stops that the "Press [Enter] to boot" prompt = without doing the 10-second countdown. Prior to disabling the beastie menu, it would sit at the menu and wait = for Enter. /boot/loader.conf: geom_mirror_load=3D"YES" beastie_disable=3D"YES" autoboot_delay=3D"10" I've checked /boot/defaults/loader.conf, and it matches that on a system = that boots normally. Any ideas? Guy From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 16:08:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6EA70BCF for ; Fri, 1 Mar 2013 16:08:05 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 28EDE75C for ; Fri, 1 Mar 2013 16:08:04 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.local [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id r21G83va096309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Mar 2013 10:08:04 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 2013 10:08:03 -0600 From: dweimer To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <5130CD1C.90709@denninger.net> References: <5130BA35.5060809@denninger.net> <5130CD1C.90709@denninger.net> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:08:05 -0000 On 03/01/2013 9:45 am, Karl Denninger wrote: >> >> I briefly did something like this between two FreeNAS boxes, it >> seemed >> to work well, but my secondary Box wasn't quite up to par hardware. >> Combine that with the lack of necessary internet bandwidth with a >> second physical location in case of something really disastrous, like >> a tornado or fire destroying my house. I ended up just using an >> eSATA >> drive dock and Bacula, with a few external drives rotated regularly >> into my office at work, rather than upgrading the secondary box. >> >> If you have the secondary box that is adequate, and either offsite >> backups aren't a concern or you have a big enough pipe to a secondary >> location that houses the backup this should work. >> >> I would recommend testing your incremental snapshot rotation, I never >> did test a restore from anything but the most recent set of data when >> I was running my setup, I did however save a weeks worth of hourly >> snapshots on a couple of the more rapidly changing data sets. >> > I rotate the disaster disks out to a safe-deposit box at the bank, and > they're geli-encrypted, so if stolen they're worthless to the thief > (other than their cash value as a drive) and if the building goes > "poof" > I have the ones in the vault to recover from. There's the potential > for > loss up to the rotation time of course but that is the same risk I had > with all UFS filesystems. > > I've tested the restores onto a spare box and it appears to work as > expected... > > Thanks for the comments! Yes, good point on the Geli encryption, I do that as well on my external backup drives, didn't think to mention that in the last post. I have considered the safe-Deposit box as well, but our office building at work is fairly well secured seeing as it houses the main data-center for our company, doors locked 24 hours a day, with electronic locks that log all entries. Its also an old brick and concrete building, that has survived a direct Tornado hit about 15 years ago with only very minor cosmetic exterior damage, to the awning over the front stairs and the Company logo above it. I feel fairly secure in keeping the disk drives there, and if ever need my offsite backup at 3:00am I can go get it rather than be stuck waiting for the bank to open. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 16:11:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6D66D21 for ; Fri, 1 Mar 2013 16:11:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA6078A for ; Fri, 1 Mar 2013 16:11:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r21GBdZb053668 for ; Fri, 1 Mar 2013 10:11:39 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Mar 1 10:11:39 2013 Message-ID: <5130D336.3000004@denninger.net> Date: Fri, 01 Mar 2013 10:11:34 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> <5130CD1C.90709@denninger.net> In-Reply-To: X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130301-0, 03/01/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:11:39 -0000 On 3/1/2013 10:08 AM, dweimer wrote: > On 03/01/2013 9:45 am, Karl Denninger wrote: >>> >>> I briefly did something like this between two FreeNAS boxes, it seemed >>> to work well, but my secondary Box wasn't quite up to par hardware. >>> Combine that with the lack of necessary internet bandwidth with a >>> second physical location in case of something really disastrous, like >>> a tornado or fire destroying my house. I ended up just using an eSATA >>> drive dock and Bacula, with a few external drives rotated regularly >>> into my office at work, rather than upgrading the secondary box. >>> >>> If you have the secondary box that is adequate, and either offsite >>> backups aren't a concern or you have a big enough pipe to a secondary >>> location that houses the backup this should work. >>> >>> I would recommend testing your incremental snapshot rotation, I never >>> did test a restore from anything but the most recent set of data when >>> I was running my setup, I did however save a weeks worth of hourly >>> snapshots on a couple of the more rapidly changing data sets. >>> >> I rotate the disaster disks out to a safe-deposit box at the bank, and >> they're geli-encrypted, so if stolen they're worthless to the thief >> (other than their cash value as a drive) and if the building goes "poof" >> I have the ones in the vault to recover from. There's the potential for >> loss up to the rotation time of course but that is the same risk I had >> with all UFS filesystems. >> >> I've tested the restores onto a spare box and it appears to work as >> expected... >> >> Thanks for the comments! > > Yes, good point on the Geli encryption, I do that as well on my > external backup drives, didn't think to mention that in the last > post. I have considered the safe-Deposit box as well, but our office > building at work is fairly well secured seeing as it houses the main > data-center for our company, doors locked 24 hours a day, with > electronic locks that log all entries. Its also an old brick and > concrete building, that has survived a direct Tornado hit about 15 > years ago with only very minor cosmetic exterior damage, to the awning > over the front stairs and the Company logo above it. I feel fairly > secure in keeping the disk drives there, and if ever need my offsite > backup at 3:00am I can go get it rather than be stuck waiting for the > bank to open. > I keep two copies on-site (rsync'd from one to the other), both offline when not actively being written to, and rotate the second with one in the vault. When the vault copy is rotated on the next cycle it is sync'd automatically. So I have two shots at a restore on-site all the time; the "last chance" one is in the vault in the event the building is destroyed and if that happens the delay until the bank opens is probably the least of my problems. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 16:35:24 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B551F92C; Fri, 1 Mar 2013 16:35:24 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 649198C4; Fri, 1 Mar 2013 16:35:24 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r21GZNrK097118; Fri, 1 Mar 2013 11:35:23 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <5130D8E0.3020605@sentex.net> Date: Fri, 01 Mar 2013 11:35:44 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> In-Reply-To: <201302281843.r1SIhoaq004371@svn.freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:35:24 -0000 On 2/28/2013 1:43 PM, Dag-Erling Smørgrav wrote: > Author: des > Date: Thu Feb 28 18:43:50 2013 > New Revision: 247485 > URL: http://svnweb.freebsd.org/changeset/base/247485 > > Log: > Pull in OpenSSH 6.1 from head. Hi, I updated a box to RELENG_9 with this change, and I can no longer ssh from my secure crt client. I have a stock sshd_config, but when I connect, cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth] Starting the daemon in debug mode below. If I change the first cipher offered to blowfish, it works. /usr/sbin/sshd -ddd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 219 debug2: parse_server_config: config /etc/ssh/sshd_config len 219 debug3: /etc/ssh/sshd_config:54 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/ssh/sshd_config:122 setting Subsystem sftp /usr/libexec/sftp-server debug1: HPN Buffer Size: 131072 debug1: sshd version OpenSSH_6.1p1_hpn13v11 FreeBSD-20120901 debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type ECDSA debug1: private host key: #2 type 3 ECDSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug2: fd 4 setting O_NONBLOCK debug3: ssh_sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 22 on ::. debug1: Server TCP RWIN socket size: 131072 debug1: HPN Buffer Size: 131072 Server listening on :: port 22. debug2: fd 5 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. debug1: Server TCP RWIN socket size: 131072 debug1: HPN Buffer Size: 131072 Server listening on 0.0.0.0 port 22. debug1: fd 6 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 9 config len 219 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9 debug1: inetd sockets after dupping: 4, 4 debug1: res_init() Connection from 2607:f3e0:0:4:f025:8813:7603:7e4a port 52567 debug1: HPN Disabled: 0, HPN Buffer Size: 131072 debug1: Client protocol version 2.0; client software version SecureCRT_6.6.1 (x64 build 289) SecureCRT debug1: no match: SecureCRT_6.6.1 (x64 build 289) SecureCRT debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1_hpn13v11 FreeBSD-20120901 debug2: fd 4 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing rlimit sandbox debug2: Network child is on pid 2667 debug3: preauth child monitor started debug3: privsep user:group 22:22 [preauth] debug1: permanently_set_uid: 22/22 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth] debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] debug2: kex_parse_kexinit: reserved 0 [preauth] debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] debug2: kex_parse_kexinit: ssh-dss,ssh-rsa,x509v3-sign-rsa,x509v3-sign-dss [preauth] debug2: kex_parse_kexinit: aes128-cbc,aes256-cbc,aes256-ctr,aes192-ctr,aes128-ctr,aes192-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour [preauth] debug2: kex_parse_kexinit: aes128-cbc,aes256-cbc,aes256-ctr,aes192-ctr,aes128-ctr,aes192-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour [preauth] debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac-64@openssh.com [preauth] debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac-64@openssh.com [preauth] debug2: kex_parse_kexinit: none [preauth] debug2: kex_parse_kexinit: none [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: [preauth] debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] debug2: kex_parse_kexinit: reserved 0 [preauth] debug2: mac_setup: found hmac-sha1 [preauth] debug1: kex: client->server aes128-cbc hmac-sha1 none [preauth] debug2: mac_setup: found hmac-sha1 [preauth] debug1: kex: server->client aes128-cbc hmac-sha1 none [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] debug3: mm_request_send entering: type 0 [preauth] debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth] debug3: mm_request_receive_expect entering: type 1 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 2048 debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_choose_dh: remaining 0 [preauth] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] debug2: dh_gen_key: priv key bits set: 181/320 [preauth] debug2: bits set: 1008/2048 [preauth] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] debug2: bits set: 1009/2048 [preauth] debug3: mm_key_sign entering [preauth] debug3: mm_request_send entering: type 4 [preauth] debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] debug3: mm_request_receive_expect entering: type 5 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x803017180(55) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] debug2: kex_derive_keys [preauth] debug2: set_newkeys: mode 1 [preauth] cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth] debug1: do_cleanup [preauth] debug3: PAM: sshpam_thread_cleanup entering [preauth] debug3: mm_request_receive entering debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: Killing privsep child 2667 -- ------------------- 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 Fri Mar 1 16:50:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6BAA4BC8 for ; Fri, 1 Mar 2013 16:50:59 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 36A3596B for ; Fri, 1 Mar 2013 16:50:58 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-177-98-144.range86-177.btcentralplus.com [86.177.98.144]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 07C62450CF; Fri, 1 Mar 2013 16:50:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.7.4 isis.morrow.me.uk 07C62450CF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1362156651; bh=wDIt0NTPRsgQTWcLqwRmr5bNEKSBLzWyQ5f602fOgsU=; h=Date:From:To:Subject:In-Reply-To; b=xqEwt/ziNn39mlUi4jGsUBNfAbAKjM+b2M0PqKSLYzJSYE/eYkGErZbpPTI5cVGjf mkDeEl+2qWTt1yfYGt0L3cJX3GGcn7cpQdxw8mmSxMwqOfpRRj2AL0vD7w/myJvpPm JVfGYnxrOSfNjnkmm6X0WUQ3BfznBNuvMefenW4s= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 834409BB6; Fri, 1 Mar 2013 16:50:45 +0000 (GMT) Date: Fri, 1 Mar 2013 16:50:45 +0000 From: Ben Morrow To: karl@denninger.net, freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Message-ID: <20130301165040.GA26251@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5130BA35.5060809@denninger.net> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 16:50:59 -0000 Quoth Karl Denninger : > Dabbling with ZFS now, and giving some thought to how to handle backup > strategies. [...] > > Take a base snapshot immediately and zfs send it to offline storage. > Take an incremental at some interval (appropriate for disaster recovery) > and zfs send THAT to stable storage. > > If I then restore the base and snapshot, I get back to where I was when > the latest snapshot was taken. I don't need to keep the incremental > snapshot for longer than it takes to zfs send it, so I can do: > > zfs snapshot pool/some-filesystem@unique-label > zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label > zfs destroy pool/some-filesystem@unique-label > > and that seems to work (and restore) just fine. For backup purposes it's worth using the -R and -I options to zfs send rather than -i. This will preserve the other snapshots, which can be important. > Am I looking at this the right way here? Provided that the base backup > and incremental are both readable, it appears that I have the disaster > case covered, and the online snapshot increments and retention are > easily adjusted and cover the "oops" situations without having to resort > to the backups at all. > > This in turn means that keeping more than two incremental dumps offline > has little or no value; the second merely being taken to insure that > there is always at least one that has been written to completion without > error to apply on top of the base. That in turn makes the backup > storage requirement based only on entropy in the filesystem and not time > (where the "tower of Hanoi" style dump hierarchy imposed both a time AND > entropy cost on backup media.) No, that's not true. Since you keep taking successive increments from a fixed base, the size of those increments will increase over time (each increment will include all net filesystem activity since the base snapshot). In UFS terms, it's equivalent to always taking level 1 dumps. Unlike with UFS, the @base snapshot will also start using increasing amounts of space in the source zpool. I don't know what medium you're backing up to (does anyone use tape any more?) but when backing up to disk I much prefer to keep the backup in the form of a filesystem rather than as 'zfs send' streams. One reason for this is that I believe that new versions of the ZFS code are more likely to be able to correctly read old versions of the filesystem than old versions of the stream format; this may not be correct any more, though. Another reason is that it means I can do 'rolling snapshot' backups. I do an initial dump like this # zpool is my working pool # bakpool is a second pool I am backing up to zfs snapshot -r zpool/fs@dump zfs send -R zpool/fs@dump | zfs recv -vFd bakpool That pipe can obviously go through ssh or whatever to put the backup on a different machine. Then to make an increment I roll forward the snapshot like this zfs rename -r zpool/fs@dump dump-old zfs snapshot -r zpool/fs@dump zfs send -R -I @dump-old zpool/fs@dump | zfs recv -vFd bakpool zfs destroy -r zpool/fs@dump-old zfs destroy -r bakpool/fs@dump-old (Notice that the increment starts at a snapshot called @dump-old on the send side but at a snapshot called @dump on the recv side. ZFS can handle this perfectly well, since it identifies snapshots by UUID, and will rename the bakpool snapshot as part of the recv.) This brings the filesystem on bakpool up to date with the filesystem on zpool, including all snapshots, but never creates an increment with more than one backup interval's worth of data in. If you want to keep more history on the backup pool than the source pool, you can hold off on destroying the old snapshots, and instead rename them to something unique. (Of course, you could always give them unique names to start with, but I find it more convenient not to.) Ben From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 17:23:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FA7A8BA for ; Fri, 1 Mar 2013 17:23:44 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 079B1AC5 for ; Fri, 1 Mar 2013 17:23:43 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r21HNVmv030310; Fri, 1 Mar 2013 12:23:31 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Fri, 01 Mar 2013 12:23:31 -0500 (EST) Date: Fri, 1 Mar 2013 12:23:31 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ben Morrow Subject: Re: Musings on ZFS Backup strategies In-Reply-To: <20130301165040.GA26251@anubis.morrow.me.uk> Message-ID: References: <20130301165040.GA26251@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, karl@denninger.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 17:23:44 -0000 On Fri, 1 Mar 2013, Ben Morrow wrote: > Quoth Karl Denninger : >> Dabbling with ZFS now, and giving some thought to how to handle backup >> strategies. > [...] >> >> Take a base snapshot immediately and zfs send it to offline storage. >> Take an incremental at some interval (appropriate for disaster recovery) >> and zfs send THAT to stable storage. >> >> If I then restore the base and snapshot, I get back to where I was when >> the latest snapshot was taken. I don't need to keep the incremental >> snapshot for longer than it takes to zfs send it, so I can do: >> >> zfs snapshot pool/some-filesystem@unique-label >> zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label >> zfs destroy pool/some-filesystem@unique-label >> >> and that seems to work (and restore) just fine. > > For backup purposes it's worth using the -R and -I options to zfs send > rather than -i. This will preserve the other snapshots, which can be > important. > >> Am I looking at this the right way here? Provided that the base backup >> and incremental are both readable, it appears that I have the disaster >> case covered, and the online snapshot increments and retention are >> easily adjusted and cover the "oops" situations without having to resort >> to the backups at all. >> >> This in turn means that keeping more than two incremental dumps offline >> has little or no value; the second merely being taken to insure that >> there is always at least one that has been written to completion without >> error to apply on top of the base. That in turn makes the backup >> storage requirement based only on entropy in the filesystem and not time >> (where the "tower of Hanoi" style dump hierarchy imposed both a time AND >> entropy cost on backup media.) > > No, that's not true. Since you keep taking successive increments from a > fixed base, the size of those increments will increase over time (each > increment will include all net filesystem activity since the base > snapshot). In UFS terms, it's equivalent to always taking level 1 dumps. > Unlike with UFS, the @base snapshot will also start using increasing > amounts of space in the source zpool. > > I don't know what medium you're backing up to (does anyone use tape any > more?) but when backing up to disk I much prefer to keep the backup in > the form of a filesystem rather than as 'zfs send' streams. One reason > for this is that I believe that new versions of the ZFS code are more > likely to be able to correctly read old versions of the filesystem than > old versions of the stream format; this may not be correct any more, > though. Yes, we still use a couple of DLT autoloaders and have nightly incrementals and weekly fulls. This is the problem I have with converting to ZFS. Our typical recovery is when a user says they need a directory or set of files from a week or two ago. Using dump from tape, I can easily extract *just* the necessary files. I don't need a second system to restore to, so that I can then extract the file. dump (and ufsdump for our Solaris boxes) _just work_, and we can go back many many years and they will still work. If we convert to ZFS, I'm guessing we'll have to do nightly incrementals with 'tar' instead of 'dump' as well as doing ZFS snapshots for fulls. This topic is very interesting to me, as we're at the point now (with Solaris 11 refusing to even boot from anything but ZFS) that we have to consider ZFS. -- DE From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 17:48:11 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EE479F4C; Fri, 1 Mar 2013 17:48:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 95C10C24; Fri, 1 Mar 2013 17:48:11 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r21HmB9E012339; Fri, 1 Mar 2013 12:48:11 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <5130E9F1.6050308@sentex.net> Date: Fri, 01 Mar 2013 12:48:33 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> In-Reply-To: <5130D8E0.3020605@sentex.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 17:48:12 -0000 On 3/1/2013 11:35 AM, Mike Tancsa wrote: > On 2/28/2013 1:43 PM, Dag-Erling Smørgrav wrote: >> Author: des >> Date: Thu Feb 28 18:43:50 2013 >> New Revision: 247485 >> URL: http://svnweb.freebsd.org/changeset/base/247485 >> >> Log: >> Pull in OpenSSH 6.1 from head. > > Hi, > I updated a box to RELENG_9 with this change, and I can no longer ssh > from my secure crt client. I have a stock sshd_config, but when I connect, > > cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth] OK, so it looks like something to do with hardware crypto. If I unload aesni.ko and restart sshd, it works, even with aes128-cbc which I guess it was trying to use cryptodev ---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 Fri Mar 1 17:55:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3EF46270 for ; Fri, 1 Mar 2013 17:55:33 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by mx1.freebsd.org (Postfix) with ESMTP id CA24DD2D for ; Fri, 1 Mar 2013 17:55:32 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id e51so2633723eek.37 for ; Fri, 01 Mar 2013 09:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uCWyI+xvYUgehAukdUcKbVVFw7uCGivX29AhRu1GOY4=; b=VuRXWAAtFjIHPhlTeqTeXNXYP0HGa3u/iE2BA+MR3Np5Mbe0nsE8RsGRMMNFHPro82 gPxkI+wnMc5zPstNAhYF2HzEhJMkBKgsSGXtr8fwMAS5wFy4xmz+xsUE8bF/4bqWhyIx l4NIuhdotv4QytXLEnIONAMOIn3ePoFElbtCmg/UGDIIpuQLyiljDLAxt531YfELJL1p vyngeuzKySVAXwIkJTQBg5EvBNq04/ma03o/xN5Fyehe+CN/1TyvOrYx+RLEtZ2FJoVK TBWfJUkWzCZtP4sRHLXSMSfQrG2MsAoUKyPkE5RzWLiyuHaKifIXa8UVuwY1Vq+xxkHh v+5A== X-Received: by 10.14.216.198 with SMTP id g46mr29962827eep.30.1362160526011; Fri, 01 Mar 2013 09:55:26 -0800 (PST) Received: from [192.168.1.128] ([91.196.229.122]) by mx.google.com with ESMTPS id s3sm18303048eem.4.2013.03.01.09.55.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 09:55:24 -0800 (PST) Message-ID: <5130EB8A.7060706@gmail.com> Date: Fri, 01 Mar 2013 19:55:22 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Karl Denninger , freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> In-Reply-To: <5130BA35.5060809@denninger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 17:55:33 -0000 01.03.2013 16:24, Karl Denninger: > Dabbling with ZFS now, and giving some thought to how to handle backup > strategies. > > ZFS' snapshot capabilities have forced me to re-think the way that I've > handled this. Previously near-line (and offline) backup was focused on > being able to handle both disasters (e.g. RAID adapter goes nuts and > scribbles on the entire contents of the array), a double-disk (or worse) > failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just > rm -rf'd something I'd rather not!" > > ZFS makes snapshots very cheap, which means you can resolve the "aw > crap" situation without resorting to backups at all. This turns the > backup situation into a disaster recovery one. > > And that in turn seems to say that the ideal strategy looks more like: > > Take a base snapshot immediately and zfs send it to offline storage. > Take an incremental at some interval (appropriate for disaster recovery) > and zfs send THAT to stable storage. > > If I then restore the base and snapshot, I get back to where I was when > the latest snapshot was taken. I don't need to keep the incremental > snapshot for longer than it takes to zfs send it, so I can do: > > zfs snapshot pool/some-filesystem@unique-label > zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label > zfs destroy pool/some-filesystem@unique-label > > and that seems to work (and restore) just fine. Yes, I'm working with backups the same way, I wrote a simple script that synchronizes two filesystems between distant servers. I also use the same script to synchronize bushy filesystems (with hundred thousands of files) where rsync produces a too big load for synchronizing. https://github.com/kworr/zfSnap/commit/08d8b499dbc2527a652cddbc601c7ee8c0c23301 I left it where it was but I was also planning to write some purger for snapshots that would automatically purge snapshots when pool gets low on space. Never hit that yet. > Am I looking at this the right way here? Provided that the base backup > and incremental are both readable, it appears that I have the disaster > case covered, and the online snapshot increments and retention are > easily adjusted and cover the "oops" situations without having to resort > to the backups at all. > > This in turn means that keeping more than two incremental dumps offline > has little or no value; the second merely being taken to insure that > there is always at least one that has been written to completion without > error to apply on top of the base. That in turn makes the backup > storage requirement based only on entropy in the filesystem and not time > (where the "tower of Hanoi" style dump hierarchy imposed both a time AND > entropy cost on backup media.) Well, snapshots can pose a value in a longer timeframe depending on data. Being able to restore some file accidentally deleted two month ago already saved 2k$ for one of our customers. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 18:59:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 975E6588; Fri, 1 Mar 2013 18:59:22 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 7682BFEB; Fri, 1 Mar 2013 18:59:21 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-177-98-144.range86-177.btcentralplus.com [86.177.98.144]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 8D19A450CF; Fri, 1 Mar 2013 18:59:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.7.4 isis.morrow.me.uk 8D19A450CF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1362164360; bh=OfgCeCN47ljkxj96dJRhk1CvGEGa/oH7nYZVjqyYdy4=; h=Date:From:To:Subject:References:In-Reply-To; b=Olni1hhWjggverVR6f/4975H8w+YRtCbqaeJu1oTcfWmRwVL2Xn/5vMETn8DMRidg 1kfcxpouWotAWrkHjpFpZHVR5eYeX/bYEWg99FXUkBwWV3h/SoKTpT328cjaFpEoNb eFvfRZ9jnPwDe4WLZm2UHAhmUoxXUCWUgEcKHQu0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 7857D9BE2; Fri, 1 Mar 2013 18:59:16 +0000 (GMT) Date: Fri, 1 Mar 2013 18:59:16 +0000 From: Ben Morrow To: deischen@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Message-ID: <20130301185912.GA27546@anubis.morrow.me.uk> References: <20130301165040.GA26251@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:59:22 -0000 Quoth Daniel Eischen : > > Yes, we still use a couple of DLT autoloaders and have nightly > incrementals and weekly fulls. This is the problem I have with > converting to ZFS. Our typical recovery is when a user says > they need a directory or set of files from a week or two ago. > Using dump from tape, I can easily extract *just* the necessary > files. I don't need a second system to restore to, so that > I can then extract the file. As Karl said originally, you can do that with snapshots without having to go to your backups at all. With the right arrangements (symlinks to the .zfs/snapshot/* directories, or just setting the snapdir property to 'visible') you can make it so users can do this sort of restore themselves without having to go through you. Ben From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 19:18:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A054155; Fri, 1 Mar 2013 19:18:33 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id CD2CE10CE; Fri, 1 Mar 2013 19:18:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r21IoU8C047635; Sat, 2 Mar 2013 05:50:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 2 Mar 2013 05:50:30 +1100 (EST) From: Ian Smith To: Darren Pilgrim Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? In-Reply-To: <512F23AC.1000003@bluerosetech.com> Message-ID: <20130302042828.J32142@sola.nimnet.asn.au> References: <512EB5BD.1020803@bluerosetech.com> <20130228014635.GB70215@glenbarber.us> <512F23AC.1000003@bluerosetech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Glen Barber , Adrian Chadd , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:18:33 -0000 On Thu, 28 Feb 2013 01:30:20 -0800, Darren Pilgrim wrote: > On 2013-02-27 18:23, Adrian Chadd wrote: > > Hm, have you disabled that CAM target layer stuff at boot? It's likely > > tying up some RAM. > > Disabling CTL let cc1plus get is resident size up to 167 MB, but that still > wasn't enough. Building clang is simply too memory intensive. :/ It is on anything less than 384MB even with kern.cam.ctl.disable=1 here, being on a thinkpad T23, 1133MHz P3-M on 9.1-R sources. At 256MB - the minimum earlier that completed installation without disabling CTL - swap often sat at ~14MB but blew out to around 165MB building those huge llvm libraries - cc1plus 332M, 173M resident was one top I snipped, but I can't say I caught the biggest. I let it finish anyway: 7h40m! When I ran buildworld again (as before, straight, no arguments) after removing /usr/obj and adding WITHOUT_CLANG=yes to /etc/src.conf (thanks Glen), I expected big savings but was surprised when it ran just 3h32m. Then I added 128MB (to 384MB) and repeated the first buildworld (incl. clang) expecting huge savings as it'd only touched swap to about 12MB a time or two, mostly having 100MB+ of free memory .. wow, down to 7h02m! Here at least, building llvm libs and clang doubles buildworld time! and extends /usr/obj from 675MB to 1GB. > To the buildbox! When I take it back to 768MB, that'll be my buildbox! :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 19:37:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1244F786 for ; Fri, 1 Mar 2013 19:37:02 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [174.136.100.66]) by mx1.freebsd.org (Postfix) with ESMTP id F2FD1119E for ; Fri, 1 Mar 2013 19:37:01 +0000 (UTC) Received: from chombo.houseloki.net (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 719B8E6001; Fri, 1 Mar 2013 11:36:55 -0800 (PST) Received: from [127.0.0.1] (ivo.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id 7F62178A; Fri, 1 Mar 2013 11:36:54 -0800 (PST) Message-ID: <5131035A.2050803@bluerosetech.com> Date: Fri, 01 Mar 2013 11:36:58 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Smith Subject: Re: Building RELENG_9 (or RELENG_9_*) on a small machine? References: <512EB5BD.1020803@bluerosetech.com> <20130228014635.GB70215@glenbarber.us> <512F23AC.1000003@bluerosetech.com> <20130302042828.J32142@sola.nimnet.asn.au> In-Reply-To: <20130302042828.J32142@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:37:02 -0000 On 2013-03-01 10:50, Ian Smith wrote: > At 256MB - the > minimum earlier that completed installation without disabling CTL - swap > often sat at ~14MB but blew out to around 165MB building those huge llvm > libraries - cc1plus 332M, 173M resident was one top I snipped, but I > can't say I caught the biggest. I had top running throughout a build and saw cc1plus reach 460 MB with 171MB resident, at that point CPU was down to about 4% and the system was hammering swap. As a testament to FreeBSD's robustness, I could still log in via ssh, start screened shells, and generally conduct admin tasks while cc1plus beat the crap out of my VM. Even start and stop other services. > Then I added 128MB (to 384MB) and repeated the first buildworld (incl. > clang) expecting huge savings as it'd only touched swap to about 12MB a > time or two, mostly having 100MB+ of free memory .. wow, down to 7h02m! For 9.x, I changed my notes to "256 MB to run, 768 MB to build". For 8.x, the numbers were 192 MB to run, 512 MB to build. > Here at least, building llvm libs and clang doubles buildworld time! and > extends /usr/obj from 675MB to 1GB. I'll be doing `make buildkernel buildworld` ET and size comparisons between RELENG_8_3 and RELENG_9_1 when I test out my buildbox. I'd like to gather memory usage metrics as well, if someone knows some tricks for that. My current approach is somewhat crude. :) If there's interest I'll follow up with the results here. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 19:44:57 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D869E10; Fri, 1 Mar 2013 19:44:57 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 11C9C11FD; Fri, 1 Mar 2013 19:44:56 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 80201A9A8; Fri, 1 Mar 2013 19:44:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2602E9CFF; Fri, 1 Mar 2013 20:44:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> Date: Fri, 01 Mar 2013 20:44:53 +0100 In-Reply-To: <5130E9F1.6050308@sentex.net> (Mike Tancsa's message of "Fri, 01 Mar 2013 12:48:33 -0500") Message-ID: <867glqsy4q.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:44:57 -0000 Mike Tancsa writes: > OK, so it looks like something to do with hardware crypto. If I unload > aesni.ko and restart sshd, it works, even with aes128-cbc which I guess > it was trying to use cryptodev Are you sure this was due to the OpenSSH update, and not the OpenSSL update a few days ago? Can you try to roll back to r247484? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 19:59:45 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 882F4587; Fri, 1 Mar 2013 19:59:45 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE341451; Fri, 1 Mar 2013 19:59:45 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r21JxhRG036669; Fri, 1 Mar 2013 14:59:43 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <513108C4.10501@sentex.net> Date: Fri, 01 Mar 2013 15:00:04 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> In-Reply-To: <867glqsy4q.fsf@ds4.des.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 19:59:45 -0000 On 3/1/2013 2:44 PM, Dag-Erling Smørgrav wrote: > Mike Tancsa writes: >> OK, so it looks like something to do with hardware crypto. If I unload >> aesni.ko and restart sshd, it works, even with aes128-cbc which I guess >> it was trying to use cryptodev > > Are you sure this was due to the OpenSSH update, and not the OpenSSL > update a few days ago? Can you try to roll back to r247484? I didnt think openssl got updated on RELENG_9 ? http://svnweb.freebsd.org/base?view=revision&revision=247484 ---Mike > > DES -- ------------------- 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 Fri Mar 1 20:09:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F41FB846 for ; Fri, 1 Mar 2013 20:09:49 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id A47D51508 for ; Fri, 1 Mar 2013 20:09:49 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.local [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id r21K9lPK006538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Mar 2013 14:09:47 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Mar 2013 14:09:47 -0600 From: dweimer To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <20130301192528.GA79829@neutralgood.org> References: <5130BA35.5060809@denninger.net> <5130CD1C.90709@denninger.net> <20130301192528.GA79829@neutralgood.org> Message-ID: <960a34e583e40def0a60df2b889380bb@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:09:50 -0000 On 03/01/2013 1:25 pm, kpneal@pobox.com wrote: > On Fri, Mar 01, 2013 at 09:45:32AM -0600, Karl Denninger wrote: >> I rotate the disaster disks out to a safe-deposit box at the bank, >> and >> they're geli-encrypted, so if stolen they're worthless to the thief >> (other than their cash value as a drive) and if the building goes >> "poof" >> I have the ones in the vault to recover from. There's the potential >> for >> loss up to the rotation time of course but that is the same risk I >> had >> with all UFS filesystems. > What do you do about geli keys? Encrypted backups aren't much use if > you can't unencrypt them. In my case I set them up with a pass-phrase only, I can mount them on any FreeBSD system using geli attach ... then enter pass-phrase when prompted. It is less secure than the key method (just because the pass-phrase is far shorter than a key would be), but it ensures as long as I can remember the pass-phrase I can access the data. However my backups in this method are personal data, worse case scenario is someone steals my identity, personal photos, and iTunes library. My bank accounts don't have enough money in them to make it worth, someone going through the time and effort to get the data off the disks. The pass-phrase I picked uses all the good practices of mixed case, special characters, and its not something easy to guess even by people who know me well. It would be far easier to break into my house and get the data that way, than break the encryption, on the external backup media. If I was say backing up a corporate data with this method and my company did defense research, well I would probably use both a pass-phrase and key combination and store an offsite copy of the key in a separate secure location from the media. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 20:34:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C13648F; Fri, 1 Mar 2013 20:34:32 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB371674; Fri, 1 Mar 2013 20:34:31 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 2FAFFAA3A; Fri, 1 Mar 2013 20:34:31 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 00ACD9D07; Fri, 1 Mar 2013 21:34:30 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> Date: Fri, 01 Mar 2013 21:34:30 +0100 In-Reply-To: <513108C4.10501@sentex.net> (Mike Tancsa's message of "Fri, 01 Mar 2013 15:00:04 -0500") Message-ID: <8638wesvu1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:34:32 -0000 Mike Tancsa writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Are you sure this was due to the OpenSSH update, and not the OpenSSL > > update a few days ago? Can you try to roll back to r247484? > I didnt think openssl got updated on RELENG_9 ? Ah, you're right. There is an OpenSSL commit immediately before my OpenSSH commit in src/secure, but it's from last July :) Can you try to connect against each version in turn while running tcpdump or wireshark and show me the pre-kex handshake and proposal exchange (basically, everything that's transmitted in cleartext) in both cases? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 20:34:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8054B49C for ; Fri, 1 Mar 2013 20:34:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4661677 for ; Fri, 1 Mar 2013 20:34:40 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r21KYd9X005747; Fri, 1 Mar 2013 15:34:39 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Fri, 01 Mar 2013 15:34:39 -0500 (EST) Date: Fri, 1 Mar 2013 15:34:39 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Ben Morrow Subject: Re: Musings on ZFS Backup strategies In-Reply-To: <20130301185912.GA27546@anubis.morrow.me.uk> Message-ID: References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:34:40 -0000 On Fri, 1 Mar 2013, Ben Morrow wrote: > Quoth Daniel Eischen : >> >> Yes, we still use a couple of DLT autoloaders and have nightly >> incrementals and weekly fulls. This is the problem I have with >> converting to ZFS. Our typical recovery is when a user says >> they need a directory or set of files from a week or two ago. >> Using dump from tape, I can easily extract *just* the necessary >> files. I don't need a second system to restore to, so that >> I can then extract the file. > > As Karl said originally, you can do that with snapshots without having > to go to your backups at all. With the right arrangements (symlinks to > the .zfs/snapshot/* directories, or just setting the snapdir property to > 'visible') you can make it so users can do this sort of restore > themselves without having to go through you. It wasn't clear that snapshots were traversable as a normal directory structure. I was thinking it was just a blob that you had to roll back to in order to get anything out of it. Under our current scheme, we would remove snapshots after the next (weekly) full zfs send (nee dump), so it wouldn't help unless we kept snapshots around a lot longer. Am I correct in assuming that one could: # zfs send -R snapshot | dd obs=10240 of=/dev/rst0 to archive it to tape instead of another [system:]drive? -- DE From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 20:37:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 832838E4 for ; Fri, 1 Mar 2013 20:37:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 52DF616C0 for ; Fri, 1 Mar 2013 20:37:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r21KbWW9065908 for ; Fri, 1 Mar 2013 14:37:32 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Mar 1 14:37:32 2013 Message-ID: <51311186.1070607@denninger.net> Date: Fri, 01 Mar 2013 14:37:26 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> In-Reply-To: X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130301-0, 03/01/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:37:34 -0000 On 3/1/2013 2:34 PM, Daniel Eischen wrote: > On Fri, 1 Mar 2013, Ben Morrow wrote: > >> Quoth Daniel Eischen : >>> >>> Yes, we still use a couple of DLT autoloaders and have nightly >>> incrementals and weekly fulls. This is the problem I have with >>> converting to ZFS. Our typical recovery is when a user says >>> they need a directory or set of files from a week or two ago. >>> Using dump from tape, I can easily extract *just* the necessary >>> files. I don't need a second system to restore to, so that >>> I can then extract the file. >> >> As Karl said originally, you can do that with snapshots without having >> to go to your backups at all. With the right arrangements (symlinks to >> the .zfs/snapshot/* directories, or just setting the snapdir property to >> 'visible') you can make it so users can do this sort of restore >> themselves without having to go through you. > > It wasn't clear that snapshots were traversable as a normal > directory structure. I was thinking it was just a blob > that you had to roll back to in order to get anything out > of it. > > Under our current scheme, we would remove snapshots > after the next (weekly) full zfs send (nee dump), so > it wouldn't help unless we kept snapshots around a > lot longer. > > Am I correct in assuming that one could: > > # zfs send -R snapshot | dd obs=10240 of=/dev/rst0 > > to archive it to tape instead of another [system:]drive? > Yes. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 20:39:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 140D1A9D for ; Fri, 1 Mar 2013 20:39:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CB62216F0 for ; Fri, 1 Mar 2013 20:39:48 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r21KdgVt010209; Fri, 1 Mar 2013 15:39:42 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Fri, 01 Mar 2013 15:39:42 -0500 (EST) Date: Fri, 1 Mar 2013 15:39:42 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: kpneal@pobox.com Subject: Re: Musings on ZFS Backup strategies In-Reply-To: <20130301192949.GB79829@neutralgood.org> Message-ID: References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301192949.GB79829@neutralgood.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ben Morrow , freebsd-stable@freebsd.org, karl@denninger.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:39:49 -0000 On Fri, 1 Mar 2013, kpneal@pobox.com wrote: > On Fri, Mar 01, 2013 at 12:23:31PM -0500, Daniel Eischen wrote: >> Yes, we still use a couple of DLT autoloaders and have nightly >> incrementals and weekly fulls. This is the problem I have with >> converting to ZFS. Our typical recovery is when a user says >> they need a directory or set of files from a week or two ago. >> Using dump from tape, I can easily extract *just* the necessary >> files. I don't need a second system to restore to, so that >> I can then extract the file. >> >> dump (and ufsdump for our Solaris boxes) _just work_, and we >> can go back many many years and they will still work. If we >> convert to ZFS, I'm guessing we'll have to do nightly >> incrementals with 'tar' instead of 'dump' as well as doing >> ZFS snapshots for fulls. > > What about extended attributes? ACLs? Are those saved by tar? I think tar (as root or -p) will attempt to preserve those. -- DE From owner-freebsd-stable@FreeBSD.ORG Fri Mar 1 20:43:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1ECDFBC9 for ; Fri, 1 Mar 2013 20:43:19 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id E03051716 for ; Fri, 1 Mar 2013 20:43:18 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r21KhIRD066181 for ; Fri, 1 Mar 2013 14:43:18 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Mar 1 14:43:18 2013 Message-ID: <513112E1.80202@denninger.net> Date: Fri, 01 Mar 2013 14:43:13 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> <5130CD1C.90709@denninger.net> <20130301192528.GA79829@neutralgood.org> In-Reply-To: <20130301192528.GA79829@neutralgood.org> X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130301-0, 03/01/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 20:43:19 -0000 On 3/1/2013 1:25 PM, kpneal@pobox.com wrote: > On Fri, Mar 01, 2013 at 09:45:32AM -0600, Karl Denninger wrote: >> I rotate the disaster disks out to a safe-deposit box at the bank, and >> they're geli-encrypted, so if stolen they're worthless to the thief >> (other than their cash value as a drive) and if the building goes "poof" >> I have the ones in the vault to recover from. There's the potential for >> loss up to the rotation time of course but that is the same risk I had >> with all UFS filesystems. > What do you do about geli keys? Encrypted backups aren't much use if > you can't unencrypt them. I keep them in my head. Even my immediate family could not guess it; one of the things I mastered many years ago was "algorithmic" and very long passwords that are easy to remember but impossible for someone to guess other than by brute force, and if long enough that becomes prohibitive for the guesser. If I needed even better I'd keep the (random part of the) composite key on an external thing (e.g. thumbdrive) that is only stuffed in the box to boot and attach the drives, the removed and stored separately under separate and high security. There is no point to using a composite key IF THE RANDOM PART CAN BE STOLEN; you then are back to the security of the typed password (if any), so if you want the better level of security you need to deal with the physical security of the random portion and make sure it is NEVER on an unencrypted part of the disk itself. If you're not going to do that then a strong and long password is just as good. I can mount my backup volumes on any FreeBSD machine that has the geli framework. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 00:48:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BBC6E13; Sat, 2 Mar 2013 00:48:40 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id AA9A91F09; Sat, 2 Mar 2013 00:48:39 +0000 (UTC) Received: from [10.0.1.2] (bas2-toronto09-1176131079.dsl.bell.ca [70.26.86.7]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id r220iMNx034719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 19:44:23 -0500 (EST) (envelope-from dmagda@ee.ryerson.ca) Subject: Re: Musings on ZFS Backup strategies Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: David Magda In-Reply-To: Date: Fri, 1 Mar 2013 19:45:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4642A367-1404-4AD9-9EEF-7496006400CF@ee.ryerson.ca> References: <20130301165040.GA26251@anubis.morrow.me.uk> To: Daniel Eischen X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 00:48:40 -0000 On Mar 1, 2013, at 12:23, Daniel Eischen wrote: > dump (and ufsdump for our Solaris boxes) _just work_, and we > can go back many many years and they will still work. If we > convert to ZFS, I'm guessing we'll have to do nightly > incrementals with 'tar' instead of 'dump' as well as doing > ZFS snapshots for fulls. Keep some snapshots, and send stuff to tape after a certain amount of = time. Most (though not all) restores are usually within "x" weeks, where = "x" is a different value for each organization. (Things will be = generally asymptotic though.) So if you keep 1 week worth of snapshots, you'll probably end being able = to service (say) 25% of restore requests: the file can be grabbed = usually from yesterday's snapshot. If you keep 2 weeks' worth of = snapshots, probably catch 50% of requests. 4 weeks will give you 80%; 6 = weeks, 90%; 8 weeks, 95%.=20 Of course the more snapshots, the more spinning disk you need (using = power and generating heat). Most articles describing backup/restore best practices I've read in the = last few years have stated you want to use disk first (snapshots, VTLs, = etc.), and then clone to tape after a certain amount of time ("x" = weeks). Or rather: disk AND tape, then clone to another tape (so you = have two) and purge the disk copy after "x". So in this instance, keep snapshots around for a little while, and keep = doing your tape backups for long-term storage. Also inform people about = the .snapshot/ directory so they can possibly do some "self service" in = case they fat finger something (quicker for them, and less hassle for = help desk/IT). From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 01:04:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B69FBC9B; Sat, 2 Mar 2013 01:04:20 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 85DE81FCB; Sat, 2 Mar 2013 01:04:20 +0000 (UTC) Received: from [10.0.1.2] (bas2-toronto09-1176131079.dsl.bell.ca [70.26.86.7]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id r2213Ni9036182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 20:03:24 -0500 (EST) (envelope-from dmagda@ee.ryerson.ca) Subject: Re: Musings on ZFS Backup strategies Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: David Magda In-Reply-To: Date: Fri, 1 Mar 2013 20:04:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <442EA027-6D73-4D85-AD73-1E29DC836EF6@ee.ryerson.ca> References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301192949.GB79829@neutralgood.org> To: Daniel Eischen X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 01:04:20 -0000 On Mar 1, 2013, at 15:39, Daniel Eischen wrote: > On Fri, 1 Mar 2013, kpneal@pobox.com wrote: >=20 >> What about extended attributes? ACLs? Are those saved by tar? >=20 > I think tar (as root or -p) will attempt to preserve those. Specifically bsdtar (with libarchive) and star: https://github.com/libarchive/libarchive/wiki/TarPosix1eACLs http://www.freshports.org/archivers/star/ GNUtar is a bit tricky: older versions don't handle ACLs at all so you = have to check version numbers on your creation and extraction hosts. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 01:12:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E69B710B for ; Sat, 2 Mar 2013 01:12:04 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id AB5668D for ; Sat, 2 Mar 2013 01:12:04 +0000 (UTC) Received: from [10.0.1.2] (bas2-toronto09-1176131079.dsl.bell.ca [70.26.86.7]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id r221B8fn036634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Mar 2013 20:11:09 -0500 (EST) (envelope-from dmagda@ee.ryerson.ca) Subject: Re: Musings on ZFS Backup strategies Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: David Magda In-Reply-To: <5130EB8A.7060706@gmail.com> Date: Fri, 1 Mar 2013 20:12:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2B318078-F863-4415-8DAE-94EE4431BF4C@ee.ryerson.ca> References: <5130BA35.5060809@denninger.net> <5130EB8A.7060706@gmail.com> To: Volodymyr Kostyrko X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 01:12:05 -0000 On Mar 1, 2013, at 12:55, Volodymyr Kostyrko wrote: > Yes, I'm working with backups the same way, I wrote a simple script = that synchronizes two filesystems between distant servers. I also use = the same script to synchronize bushy filesystems (with hundred thousands = of files) where rsync produces a too big load for synchronizing. >=20 > = https://github.com/kworr/zfSnap/commit/08d8b499dbc2527a652cddbc601c7ee8c0c= 23301 There are quite a few scripts out there: http://www.freshports.org/search.php?query=3Dzfs For file level copying, where you don't want to walk the entire tree, = here is the "zfs diff" command: > zfs diff [-FHt] snapshot [snapshot|filesystem] >=20 > Describes differences between a snapshot and a successor = dataset. The > successor dataset can be a later snapshot or the current = filesystem. >=20 > The changed files are displayed including the change type. The = change > type is displayed useing a single character. If a file or = directory > was renamed, the old and the new names are displayed. http://www.freebsd.org/cgi/man.cgi?query=3Dzfs This allows one to get a quick list of files and directories, then use = tar/rsync/cp/etc. to do the actual copy (where the destination does not = have to be ZFS: e.g., NFS, ext4, Lustre, HDFS, etc.). From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 02:15:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11D619D4 for ; Sat, 2 Mar 2013 02:15:05 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id E4C7F24A for ; Sat, 2 Mar 2013 02:15:04 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-177-98-144.range86-177.btcentralplus.com [86.177.98.144]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 189C3450CF for ; Sat, 2 Mar 2013 02:15:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.7.4 isis.morrow.me.uk 189C3450CF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1362190503; bh=mrJ/8KReEBksnKVNWXW9ayOd9vzHCMTHnrG5YLTMoT8=; h=Date:From:To:Subject:References:In-Reply-To; b=1GeaEoS1GTsH+N86PoPO+a7Iod0pvuKmjlc15fojnZlqp/szVgG3iSyT3oQsQVY7v 3Wn9d4tnSeuWFTTL/+jBb5do6oVKU2mNnFNvyElrmPIU8YzhuSMeUj3P1n4N/70bya +EhX40IjaFxc8XqO7pvzA86bYC1IF3wwuzEuoCyw= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id D1C449C9B; Sat, 2 Mar 2013 02:14:59 +0000 (GMT) Date: Sat, 2 Mar 2013 02:14:59 +0000 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Message-ID: <20130302021452.GA30814@anubis.morrow.me.uk> References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301192949.GB79829@neutralgood.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <442EA027-6D73-4D85-AD73-1E29DC836EF6@ee.ryerson.ca> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 02:15:05 -0000 Quoth David Magda : > On Mar 1, 2013, at 15:39, Daniel Eischen wrote: > > On Fri, 1 Mar 2013, kpneal@pobox.com wrote: > > > >> What about extended attributes? ACLs? Are those saved by tar? > > > > I think tar (as root or -p) will attempt to preserve those. > > Specifically bsdtar (with libarchive) and star: > > https://github.com/libarchive/libarchive/wiki/TarPosix1eACLs But since ZFS doesn't support POSIX.1e ACLs that's not terribly useful... I don't believe bsdtar/libarchive supports NFSv4 ACLs yet. Ben From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 03:05:52 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 968153BD; Sat, 2 Mar 2013 03:05:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 565BD6A6; Sat, 2 Mar 2013 03:05:52 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r2235oov089437; Fri, 1 Mar 2013 22:05:51 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <51316CA3.8000301@sentex.net> Date: Fri, 01 Mar 2013 22:06:11 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> In-Reply-To: <8638wesvu1.fsf@ds4.des.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 03:05:52 -0000 On 3/1/2013 3:34 PM, Dag-Erling Smørgrav wrote: > Mike Tancsa writes: >> Dag-Erling Smørgrav writes: >>> Are you sure this was due to the OpenSSH update, and not the OpenSSL >>> update a few days ago? Can you try to roll back to r247484? >> I didnt think openssl got updated on RELENG_9 ? > > Ah, you're right. There is an OpenSSL commit immediately before my > OpenSSH commit in src/secure, but it's from last July :) > > Can you try to connect against each version in turn while running > tcpdump or wireshark and show me the pre-kex handshake and proposal > exchange (basically, everything that's transmitted in cleartext) in both > cases? The pcaps and basic wireshark output at http://tancsa.com/openssh/ ---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 Sat Mar 2 13:55:37 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 79D845D1; Sat, 2 Mar 2013 13:55:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 463C5C27; Sat, 2 Mar 2013 13:55:37 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r22DtXSI034174; Sat, 2 Mar 2013 08:55:34 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <513204E9.1040006@sentex.net> Date: Sat, 02 Mar 2013 08:55:53 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> In-Reply-To: <51316CA3.8000301@sentex.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 13:55:37 -0000 On 3/1/2013 10:06 PM, Mike Tancsa wrote: > On 3/1/2013 3:34 PM, Dag-Erling Smørgrav wrote: >> Mike Tancsa writes: >>> Dag-Erling Smørgrav writes: >>>> Are you sure this was due to the OpenSSH update, and not the OpenSSL >>>> update a few days ago? Can you try to roll back to r247484? >>> I didnt think openssl got updated on RELENG_9 ? >> >> Ah, you're right. There is an OpenSSL commit immediately before my >> OpenSSH commit in src/secure, but it's from last July :) >> >> Can you try to connect against each version in turn while running >> tcpdump or wireshark and show me the pre-kex handshake and proposal >> exchange (basically, everything that's transmitted in cleartext) in both >> cases? > > The pcaps and basic wireshark output at > > http://tancsa.com/openssh/ This PR looks to be related http://lists.freebsd.org/pipermail/freebsd-bugs/2012-September/050139.html ---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 Sat Mar 2 15:09:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F32BD8B7; Sat, 2 Mar 2013 15:09:48 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 69E4095; Sat, 2 Mar 2013 15:09:48 +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.69) (envelope-from ) id 1UBo4C-00021B-6W; Sat, 02 Mar 2013 16:09:40 +0100 Received: from h253044.upc-h.chello.nl ([62.194.253.44] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBo4C-0005vE-5c; Sat, 02 Mar 2013 16:09:40 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Ben Morrow" , "Daniel Eischen" Subject: Re: Musings on ZFS Backup strategies References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> Date: Sat, 02 Mar 2013 16:09:41 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: d3d6c6694e059b137bd8e4e2c0542d46 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 15:09:49 -0000 On Fri, 01 Mar 2013 21:34:39 +0100, Daniel Eischen wrote: > On Fri, 1 Mar 2013, Ben Morrow wrote: > >> Quoth Daniel Eischen : >>> >>> Yes, we still use a couple of DLT autoloaders and have nightly >>> incrementals and weekly fulls. This is the problem I have with >>> converting to ZFS. Our typical recovery is when a user says >>> they need a directory or set of files from a week or two ago. >>> Using dump from tape, I can easily extract *just* the necessary >>> files. I don't need a second system to restore to, so that >>> I can then extract the file. >> >> As Karl said originally, you can do that with snapshots without having >> to go to your backups at all. With the right arrangements (symlinks to >> the .zfs/snapshot/* directories, or just setting the snapdir property to >> 'visible') you can make it so users can do this sort of restore >> themselves without having to go through you. > > It wasn't clear that snapshots were traversable as a normal > directory structure. I was thinking it was just a blob > that you had to roll back to in order to get anything out > of it. That is the main benefit of snapshots. :-) You can also very easily diff files between them. Mostly a lot of data is static so it does not cost a lot to keep snapshots. There are a lot of scripts online and in ports which make a nice retention policy like e.g. 7 daily snaphots, 8 weekly, 12 monthly, 2 yearly. See below for (an incomplete list of) what I keep about my homedir at home. > Under our current scheme, we would remove snapshots > after the next (weekly) full zfs send (nee dump), so > it wouldn't help unless we kept snapshots around a > lot longer. Why not. > Am I correct in assuming that one could: > > # zfs send -R snapshot | dd obs=10240 of=/dev/rst0 > > to archive it to tape instead of another [system:]drive? Yes, your are correct. The manual page about zfs send says: 'The format of the stream is committed. You will be able to receive your streams on future versions of ZFS.' Ronald. tank/home 115G 65.6G 53.6G /home tank/home@auto-2011-10-25_19.00.yearly 16.3G - 56.8G - tank/home@auto-2012-06-06_22.00.yearly 5.55G - 53.3G - tank/home@auto-2012-09-02_20.00.monthly 2.61G - 49.3G - tank/home@auto-2012-10-15_06.00.monthly 2.22G - 49.9G - tank/home@auto-2012-11-26_13.00.monthly 2.47G - 50.2G - tank/home@auto-2013-01-07_13.00.monthly 2.56G - 51.5G - tank/home@auto-2013-01-21_13.00.weekly 1.06G - 52.4G - tank/home@auto-2013-01-28_13.00.weekly 409M - 52.3G - tank/home@auto-2013-02-04_13.00.monthly 625M - 52.5G - tank/home@auto-2013-02-11_13.00.weekly 689M - 52.5G - tank/home@auto-2013-02-16_13.00.weekly 17.7M - 52.5G - tank/home@auto-2013-02-17_13.00.daily 17.7M - 52.5G - tank/home@auto-2013-02-18_13.00.daily 17.9M - 52.5G - From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 15:21:45 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 71D30D3F for ; Sat, 2 Mar 2013 15:21:45 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 184BF147 for ; Sat, 2 Mar 2013 15:21:44 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id AFEF750AC1 for ; Sat, 2 Mar 2013 16:21:30 +0100 (CET) Received: from [IPv6:2001:16d8:ff9f::6445:44f0:ad89:d510] (unknown [IPv6:2001:16d8:ff9f:0:6445:44f0:ad89:d510]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 1BA7850ABD for ; Sat, 2 Mar 2013 16:21:25 +0100 (CET) From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Make use of RACCT and rctl Message-Id: <8A4085D7-A3BF-42C8-A0D4-4B3AAE26D288@pean.org> Date: Sat, 2 Mar 2013 16:21:24 +0100 To: stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Mar 2 16:21:30 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 513218fa27775239311582 X-DSPAM-Factors: 27, What's, 0.40000, but, 0.40000, right, 0.40000, Received*cipher+AES128, 0.40000, Also, 0.40000, have+compiled, 0.40000, memorylocked=0, 0.40000, I+try, 0.40000, Message-Id*A3BF+42C8, 0.40000, accounting, 0.40000, allocate, 0.40000, But, 0.40000, to+allocate, 0.40000, nsemop=0+nshm=0, 0.40000, Mime-Version*OS+X, 0.40000, Cant+find, 0.40000, Received*Sat+2, 0.40000, Received*client+certificate, 0.40000, Date*16, 0.40000, API, 0.40000, rctl+u, 0.40000, uname, 0.40000, jail22, 0.40000, jail22, 0.40000, Received*2+Mar, 0.40000, doesn't, 0.40000, no, 0.40000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 15:21:45 -0000 Hi! Im trying to limit memory usage for jails with the rctl API. But I don't = really get it. I have compiled the kernel with the right options and rctl show me stuff = like: jail:jail22:memoryuse:deny=3D268435456 jail:jail22:swapuse:deny=3D268435456 jail:jail20:memoryuse:deny=3D268435456 jail:jail20:swapuse:deny=3D268435456 jail:jail16:memoryuse:deny=3D268435456 jail:jail16:swapuse:deny=3D268435456 but when I try to allocate memory it doesn't seem to hit the limit. Also = when I run=20 # rctl -u jail:jail20 cputime=3D0 datasize=3D0 stacksize=3D0 coredumpsize=3D0 memoryuse=3D0 memorylocked=3D0 maxproc=3D0 openfiles=3D0 vmemoryuse=3D0 pseudoterminals=3D0 swapuse=3D0 nthr=3D0 msgqqueued=3D0 msgqsize=3D0 nmsgq=3D0 nsem=3D0 nsemop=3D0 nshm=3D0 shmsize=3D0 wallclock=3D0 it seems that no accounting is done. What's missing? Cant find anything = in the manuals. # uname -srm FreeBSD 9.1-RELEASE-p1 amd64 /Peter. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 15:24:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A6CAE54 for ; Sat, 2 Mar 2013 15:24:28 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id E397516B for ; Sat, 2 Mar 2013 15:24:27 +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.69) (envelope-from ) id 1UBoIT-0003gV-6R; Sat, 02 Mar 2013 16:24:25 +0100 Received: from h253044.upc-h.chello.nl ([62.194.253.44] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UBoIT-00068a-5F; Sat, 02 Mar 2013 16:24:25 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Karl Denninger" , freebsd-stable@freebsd.org, "Volodymyr Kostyrko" Subject: Re: Musings on ZFS Backup strategies References: <5130BA35.5060809@denninger.net> <5130EB8A.7060706@gmail.com> Date: Sat, 02 Mar 2013 16:24:28 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <5130EB8A.7060706@gmail.com> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 18b3e585b0ef946fc0f6ee9ab4fcc4ff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 15:24:28 -0000 On Fri, 01 Mar 2013 18:55:22 +0100, Volodymyr Kostyrko wrote: > 01.03.2013 16:24, Karl Denninger: >> Dabbling with ZFS now, and giving some thought to how to handle backup >> strategies. >> >> ZFS' snapshot capabilities have forced me to re-think the way that I've >> handled this. Previously near-line (and offline) backup was focused on >> being able to handle both disasters (e.g. RAID adapter goes nuts and >> scribbles on the entire contents of the array), a double-disk (or worse) >> failure, or the obvious (e.g. fire, etc) along with the "aw crap, I just >> rm -rf'd something I'd rather not!" >> >> ZFS makes snapshots very cheap, which means you can resolve the "aw >> crap" situation without resorting to backups at all. This turns the >> backup situation into a disaster recovery one. >> >> And that in turn seems to say that the ideal strategy looks more like: >> >> Take a base snapshot immediately and zfs send it to offline storage. >> Take an incremental at some interval (appropriate for disaster recovery) >> and zfs send THAT to stable storage. >> >> If I then restore the base and snapshot, I get back to where I was when >> the latest snapshot was taken. I don't need to keep the incremental >> snapshot for longer than it takes to zfs send it, so I can do: >> >> zfs snapshot pool/some-filesystem@unique-label >> zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label >> zfs destroy pool/some-filesystem@unique-label >> >> and that seems to work (and restore) just fine. > > Yes, I'm working with backups the same way, I wrote a simple script that > synchronizes two filesystems between distant servers. I also use the > same script to synchronize bushy filesystems (with hundred thousands of Your filesystems grow a lot of hair? :-) > files) where rsync produces a too big load for synchronizing. > > https://github.com/kworr/zfSnap/commit/08d8b499dbc2527a652cddbc601c7ee8c0c23301 > > I left it where it was but I was also planning to write some purger for > snapshots that would automatically purge snapshots when pool gets low on > space. Never hit that yet. > >> Am I looking at this the right way here? Provided that the base backup >> and incremental are both readable, it appears that I have the disaster >> case covered, and the online snapshot increments and retention are >> easily adjusted and cover the "oops" situations without having to resort >> to the backups at all. >> >> This in turn means that keeping more than two incremental dumps offline >> has little or no value; the second merely being taken to insure that >> there is always at least one that has been written to completion without >> error to apply on top of the base. That in turn makes the backup >> storage requirement based only on entropy in the filesystem and not time >> (where the "tower of Hanoi" style dump hierarchy imposed both a time AND >> entropy cost on backup media.) > > Well, snapshots can pose a value in a longer timeframe depending on > data. Being able to restore some file accidentally deleted two month ago > already saved 2k$ for one of our customers. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 15:33:47 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B2E6243; Sat, 2 Mar 2013 15:33:47 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0511C1; Sat, 2 Mar 2013 15:33:46 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 6057E7633; Sat, 2 Mar 2013 15:33:40 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 266069DAC; Sat, 2 Mar 2013 16:33:40 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> <513204E9.1040006@sentex.net> Date: Sat, 02 Mar 2013 16:33:39 +0100 In-Reply-To: <513204E9.1040006@sentex.net> (Mike Tancsa's message of "Sat, 02 Mar 2013 08:55:53 -0500") Message-ID: <86vc99rf3g.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 15:33:47 -0000 Mike Tancsa writes: > This PR looks to be related > > http://lists.freebsd.org/pipermail/freebsd-bugs/2012-September/050139.html That suggests a bug in the aesni driver... Can you ktrace sshd in both cases? My guess is the difference is that the new version uses hw offloading while the old version doesn't. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 15:51:20 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A565E75D; Sat, 2 Mar 2013 15:51:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 61C79274; Sat, 2 Mar 2013 15:51:20 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r22FpIuY043457; Sat, 2 Mar 2013 10:51:19 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <5132200A.8070500@sentex.net> Date: Sat, 02 Mar 2013 10:51:38 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> <513204E9.1040006@sentex.net> <86vc99rf3g.fsf@ds4.des.no> In-Reply-To: <86vc99rf3g.fsf@ds4.des.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 15:51:20 -0000 On 3/2/2013 10:33 AM, Dag-Erling Smørgrav wrote: > Mike Tancsa writes: >> This PR looks to be related >> >> http://lists.freebsd.org/pipermail/freebsd-bugs/2012-September/050139.html > > That suggests a bug in the aesni driver... OK, but the above uses the glxsb driver, not the aesni driver. Also, if at was aesni, would it not show up in the geli tests I did ? > > Can you ktrace sshd in both cases? My guess is the difference is that > the new version uses hw offloading while the old version doesn't. Done. Both files are at http://www.tancsa.com/openssh ---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 Sat Mar 2 16:02:11 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA1C0F09; Sat, 2 Mar 2013 16:02:11 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED8A326; Sat, 2 Mar 2013 16:02:11 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 9B2A876CE; Sat, 2 Mar 2013 16:02:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 625A39DB1; Sat, 2 Mar 2013 17:02:10 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> Date: Sat, 02 Mar 2013 17:02:10 +0100 In-Reply-To: <51316CA3.8000301@sentex.net> (Mike Tancsa's message of "Fri, 01 Mar 2013 22:06:11 -0500") Message-ID: <86r4jxrdrx.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:02:11 -0000 Mike Tancsa writes: > The pcaps and basic wireshark output at > > http://tancsa.com/openssh/ This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs 5.8, both with aesni loaded. Could you also ktrace the server in both cases? An easy workaround is to change the list of ciphers the server will offer to clients by adding a "Ciphers" line in /etc/ssh/sshd_config. The default is: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3= des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour Either remove the AES entries or move them further down the list. The client will normally pick the first supported cipher. As far as I can tell, SecureCRT supports all the same ciphers that OpenSSH does, so just moving arcfour{256,128} to the front of the list should work. (AFAIK, arcfour is also much faster than aes) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 16:06:49 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49FFF101; Sat, 2 Mar 2013 16:06:49 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E7CCA35E; Sat, 2 Mar 2013 16:06:48 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r22G6mQr044616; Sat, 2 Mar 2013 11:06:48 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <513223AB.8080409@sentex.net> Date: Sat, 02 Mar 2013 11:07:07 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> <86r4jxrdrx.fsf@ds4.des.no> In-Reply-To: <86r4jxrdrx.fsf@ds4.des.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:06:49 -0000 On 3/2/2013 11:02 AM, Dag-Erling Smørgrav wrote: > Mike Tancsa writes: >> The pcaps and basic wireshark output at >> >> http://tancsa.com/openssh/ > > This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs > 5.8, both with aesni loaded. Ahh, ok. I will do it later this aft. > > Could you also ktrace the server in both cases? That was the daemon in both cases. ktrace /usr/sbin/sshd -dddd > > An easy workaround is to change the list of ciphers the server will > offer to clients by adding a "Ciphers" line in /etc/ssh/sshd_config. > The default is: > > Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour > > Either remove the AES entries or move them further down the list. The > client will normally pick the first supported cipher. As far as I can > tell, SecureCRT supports all the same ciphers that OpenSSH does, so just > moving arcfour{256,128} to the front of the list should work. > > (AFAIK, arcfour is also much faster than aes) Actually, I am just doing with a freebsd openssh client ssh -c aes128-cbc testhost-with-the-issue.sentex.ca Its for sure something to do with hardware crypto offload because it works fine with a cipher that is not accelerated. ---Mike > > DES -- ------------------- 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 Sat Mar 2 16:08:55 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 913C1329; Sat, 2 Mar 2013 16:08:55 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEE5379; Sat, 2 Mar 2013 16:08:55 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 77BD076F0; Sat, 2 Mar 2013 16:08:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 4CF629DB7; Sat, 2 Mar 2013 17:08:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> <86r4jxrdrx.fsf@ds4.des.no> Date: Sat, 02 Mar 2013 17:08:54 +0100 In-Reply-To: <86r4jxrdrx.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Sat, 02 Mar 2013 17:02:10 +0100") Message-ID: <86bob1rdgp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:08:55 -0000 Dag-Erling Sm=C3=B8rgrav writes: > This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs > 5.8, both with aesni loaded. On second thought, I don't need more pcaps. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 16:15:31 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76AE44FE for ; Sat, 2 Mar 2013 16:15:31 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECFC3E2 for ; Sat, 2 Mar 2013 16:15:30 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id jc3so1767956bkc.20 for ; Sat, 02 Mar 2013 08:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=7efHv6fmzYDQYWON2+paCRyHbsuWhIsaRLakKy5a1y8=; b=us7RJeAJmzVg/iJeF6GYX6CAsbx5W4CeGFi7h4O3ffJ9WQ/Z8C8ehqqAHVo2sejXPP 5MJj/j79/0ggqxUgn3+TLxtXhd6tx0gCWaBsC4AzdITMfa+RAVj+CUdRAkOF1195M5zw A3vwjkkPm4Wa8PmR98Cp64jNfUcQaTPJrC6WfUzbbZD+wSz5IUU1ryuZL1dmTkzNYKQO cZs6FGGjZ0OX1JFfV49LJeK2GfcWO2z2L2BPrdC7kO0XQOiWy6di1rc8iTfJ4wnjBo0l Q+wzJiO+ZfzMhWcB+zkmQPooR6VpPTn9UkqQrmS8tRPJXlKD98cSVIaEPJK5AwWeFsow 0TTQ== X-Received: by 10.204.148.88 with SMTP id o24mr5308906bkv.68.1362240929584; Sat, 02 Mar 2013 08:15:29 -0800 (PST) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id k4sm3932966bkv.18.2013.03.02.08.15.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 08:15:29 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Make use of RACCT and rctl Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <8A4085D7-A3BF-42C8-A0D4-4B3AAE26D288@pean.org> Date: Sat, 2 Mar 2013 17:15:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A4085D7-A3BF-42C8-A0D4-4B3AAE26D288@pean.org> To: =?utf-8?Q?Peter_Ankerst=C3=A5l?= X-Mailer: Apple Mail (2.1283) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:15:31 -0000 Wiadomo=C5=9B=C4=87 napisana przez Peter Ankerst=C3=A5l w dniu 2 mar = 2013, o godz. 16:21: > Hi! >=20 > Im trying to limit memory usage for jails with the rctl API. But I = don't really get it. >=20 > I have compiled the kernel with the right options and rctl show me = stuff like: > jail:jail22:memoryuse:deny=3D268435456 > jail:jail22:swapuse:deny=3D268435456 > jail:jail20:memoryuse:deny=3D268435456 > jail:jail20:swapuse:deny=3D268435456 > jail:jail16:memoryuse:deny=3D268435456 > jail:jail16:swapuse:deny=3D268435456 >=20 > but when I try to allocate memory it doesn't seem to hit the limit. = Also when I run=20 > # rctl -u jail:jail20 > cputime=3D0 [..] Could you please do "jls jid name" and verify that a jail named "jail20" = is actually running? --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 16:18:54 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9758B777 for ; Sat, 2 Mar 2013 16:18:54 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA90616 for ; Sat, 2 Mar 2013 16:18:54 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id 56CE950F58 for ; Sat, 2 Mar 2013 17:18:53 +0100 (CET) Received: from [IPv6:2001:16d8:ff9f::6445:44f0:ad89:d510] (unknown [IPv6:2001:16d8:ff9f:0:6445:44f0:ad89:d510]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id CEFBC50F54; Sat, 2 Mar 2013 17:18:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Make use of RACCT and rctl From: =?utf-8?Q?Peter_Ankerst=C3=A5l?= In-Reply-To: Date: Sat, 2 Mar 2013 17:18:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <438AB334-2997-4F00-AFBA-8226687C521B@pean.org> References: <8A4085D7-A3BF-42C8-A0D4-4B3AAE26D288@pean.org> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Mar 2 17:18:53 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5132266d27771167516465 X-DSPAM-Factors: 27, 2013+at, 0.40000, Received*cipher+AES128, 0.40000, Received*id+CEFBC50F54, 0.40000, a+jail, 0.40000, In-Reply-To*3098+4D62, 0.40000, or, 0.40000, would+I, 0.40000, from, 0.40000, from, 0.40000, cut, 0.40000, verify, 0.40000, of, 0.40000, ]+>, 0.40000, But, 0.40000, From*Peter_Ankerst%c3%a5l, 0.40000, [, 0.40000, Mime-Version*OS+X, 0.40000, head+what, 0.40000, thought, 0.40000, Received*Sat+2, 0.40000, Message-Id*8226687C521B+pean.org>, 0.40000, Thanks!, 0.40000, Received*client+certificate, 0.40000, name"+and, 0.40000, name+from, 0.40000, name+from, 0.40000, References*3098+4D62, 0.40000 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:18:54 -0000 On Mar 2, 2013, at 5:15 PM, Edward Tomasz Napiera=C5=82a = wrote: >>=20 >=20 > [..] >=20 > Could you please do "jls jid name" and verify that a jail named = "jail20" is actually > running? >=20 > --=20 > If you cut off my head, what would I say? Me and my head, or me and = my body? >=20 >=20 Oh!=20 My bad, I thought it was the name from rc.conf. But of course it is the = name from the -n flag. Now everything seems to work. Thanks!= From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 16:27:15 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 475CAA88; Sat, 2 Mar 2013 16:27:15 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 05ED0678; Sat, 2 Mar 2013 16:27:14 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBpHF-000N3H-VK; Sat, 02 Mar 2013 16:27:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r22GRBxN088623; Sat, 2 Mar 2013 09:27:11 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+buk0cLfBHxLJBGaxN4Agd Subject: Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86r4jxrdrx.fsf@ds4.des.no> References: <201302281843.r1SIhoaq004371@svn.freebsd.org> <5130D8E0.3020605@sentex.net> <5130E9F1.6050308@sentex.net> <867glqsy4q.fsf@ds4.des.no> <513108C4.10501@sentex.net> <8638wesvu1.fsf@ds4.des.no> <51316CA3.8000301@sentex.net> <86r4jxrdrx.fsf@ds4.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 02 Mar 2013 09:27:11 -0700 Message-ID: <1362241631.1195.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r22GRBxN088623 Cc: stable@FreeBSD.org, svn-src-stable-9@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:27:15 -0000 On Sat, 2013-03-02 at 17:02 +0100, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa writes: > > The pcaps and basic wireshark output at > > > > http://tancsa.com/openssh/ >=20 > This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs > 5.8, both with aesni loaded. >=20 > Could you also ktrace the server in both cases? >=20 > An easy workaround is to change the list of ciphers the server will > offer to clients by adding a "Ciphers" line in /etc/ssh/sshd_config. > The default is: >=20 > Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-c= bc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour >=20 > Either remove the AES entries or move them further down the list. The > client will normally pick the first supported cipher. As far as I can > tell, SecureCRT supports all the same ciphers that OpenSSH does, so jus= t > moving arcfour{256,128} to the front of the list should work. >=20 > (AFAIK, arcfour is also much faster than aes) The last time I tried to affect the chosen cypher by manipulating the order of the list items in the config files was a couple years ago, but I found then that you just can't do that. The client side, not the server, decides on the order, and it's based on compiled-in ordering within the client code (not the client config). From the server side the only thing you can do to affect the order is leave items out of the list (it will still try the remaining list items in the client-requested order). All of this was with "OpenSSH_5.4p1_hpn13v11 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010" and may be completely out of date now. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 16:40:33 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 575AB73E for ; Sat, 2 Mar 2013 16:40:33 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by mx1.freebsd.org (Postfix) with ESMTP id E251F704 for ; Sat, 2 Mar 2013 16:40:32 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id w11so1794053bku.22 for ; Sat, 02 Mar 2013 08:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=E4L9q7wSs8vlFd0vHe9zukcafEPvgg82/783e/9Szi4=; b=OVOLJ07rkY7OIfUjs4h5uzd1yX/fpwknIBqGjEQEUPm/zs66+lWb4lbS6t6o7xT+kA M4eEt9TJHza+Zv5qLRhqV9aNHHHHau8DMt5PVjqljmmLLNVYyqGt0EhOuLpm953iPqgS LK+vBytG2ekjQ9xs0mtIRNw6CaOdgpgJ4JRgv7h3IQwnE3U5KYJdpbBmez2U7iRnHF16 dONdrQpVJJ7B7q1Jp3lIWZPC2WUPzGEo7hIks7E/L10RHo7qBqtHhMrrFxGS7nOPKOSI CTwRM1HbsPerUcDHewpOulETbgUDs1PkQ/yeZftSB6/ANkJmvQ8Ccc7ighfMATgk6PB2 IzSw== X-Received: by 10.204.132.81 with SMTP id a17mr5255738bkt.133.1362241933981; Sat, 02 Mar 2013 08:32:13 -0800 (PST) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id go8sm3948197bkc.20.2013.03.02.08.32.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 08:32:13 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Make use of RACCT and rctl Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <438AB334-2997-4F00-AFBA-8226687C521B@pean.org> Date: Sat, 2 Mar 2013 17:32:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A4085D7-A3BF-42C8-A0D4-4B3AAE26D288@pean.org> <438AB334-2997-4F00-AFBA-8226687C521B@pean.org> To: =?utf-8?Q?Peter_Ankerst=C3=A5l?= X-Mailer: Apple Mail (2.1283) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:40:33 -0000 Wiadomo=C5=9B=C4=87 napisana przez Peter Ankerst=C3=A5l w dniu 2 mar = 2013, o godz. 17:18: > On Mar 2, 2013, at 5:15 PM, Edward Tomasz Napiera=C5=82a = wrote: >>>=20 >>=20 >> [..] >>=20 >> Could you please do "jls jid name" and verify that a jail named = "jail20" is actually >> running? >>=20 >> --=20 >> If you cut off my head, what would I say? Me and my head, or me and = my body? >>=20 >>=20 > Oh!=20 > My bad, I thought it was the name from rc.conf. But of course it is = the name from the -n > flag. Now everything seems to work. Thanks! You're welcome. Please Cc: me if you have any further questions or = comments. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 20:20:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7783DD94 for ; Sat, 2 Mar 2013 20:20:58 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 217CBD7 for ; Sat, 2 Mar 2013 20:20:57 +0000 (UTC) Received: from [10.0.1.2] (bas2-toronto09-1176131079.dsl.bell.ca [70.26.86.7]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id r22KJtPw095757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Mar 2013 15:19:56 -0500 (EST) (envelope-from dmagda@ee.ryerson.ca) Subject: Re: Musings on ZFS Backup strategies Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: David Magda In-Reply-To: <20130302021452.GA30814@anubis.morrow.me.uk> Date: Sat, 2 Mar 2013 15:20:54 -0500 Content-Transfer-Encoding: 7bit Message-Id: <48FD2398-8878-483B-B2BB-228119910480@ee.ryerson.ca> References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301192949.GB79829@neutralgood.org> <20130302021452.GA30814@anubis.morrow.me.uk> To: Ben Morrow X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 20:20:58 -0000 On Mar 1, 2013, at 21:14, Ben Morrow wrote: > But since ZFS doesn't support POSIX.1e ACLs that's not terribly > useful... I don't believe bsdtar/libarchive supports NFSv4 ACLs yet. Ah yes, just noticed that. Thought it did. https://github.com/libarchive/libarchive/wiki/TarNFS4ACLs From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 22:14:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 996C487C for ; Sat, 2 Mar 2013 22:14:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2F36E6A3 for ; Sat, 2 Mar 2013 22:14:56 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r22MEqVp025168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 3 Mar 2013 09:14:53 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r22MEl7v053224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 3 Mar 2013 09:14:47 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r22MEknq053223 for freebsd-stable@freebsd.org; Sun, 3 Mar 2013 09:14:46 +1100 (EST) (envelope-from peter) Date: Sun, 3 Mar 2013 09:14:46 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies Message-ID: <20130302221446.GG286@server.rulingia.com> References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 22:14:57 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Mar-01 08:24:53 -0600, Karl Denninger wrote: >If I then restore the base and snapshot, I get back to where I was when >the latest snapshot was taken. I don't need to keep the incremental >snapshot for longer than it takes to zfs send it, so I can do: > >zfs snapshot pool/some-filesystem@unique-label >zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label >zfs destroy pool/some-filesystem@unique-label > >and that seems to work (and restore) just fine. This gives you an incremental since the base snapshot - which will probably grow in size over time. If you are storing the ZFS send streams on (eg) tape, rather than receiving them, you probably still want the "Towers of Hanoi" style backup hierarchy to control your backup volume. It's also worth noting that whilst the stream will contain the compression attributes of the filesystem(s) in it, the actual data is the stream in uncompressed >This in turn means that keeping more than two incremental dumps offline >has little or no value; the second merely being taken to insure that >there is always at least one that has been written to completion without >error to apply on top of the base. This is quite a critical point with this style of backup: The ZFS send stream is not intended as an archive format. It includes error detection but no error correction and any error in a stream renders the whole stream unusable (you can't retrieve only part of a stream). If you go this way, you probably want to wrap the stream in a FEC container (eg based on ports/comms/libfec) and/or keep multiple copies. The "recommended" approach is to do zfs send | zfs recv and store a replica of your pool (with whatever level of RAID that meets your needs). This way, you immediately detect an error in the send stream and can repeat the send. You then use scrub to verify (and recover) the replica. >(Yes, I know, I've been a ZFS resister.... ;-)) "Resistance is futile." :-) On 2013-Mar-01 15:34:39 -0500, Daniel Eischen wrote: >It wasn't clear that snapshots were traversable as a normal >directory structure. I was thinking it was just a blob >that you had to roll back to in order to get anything out >of it. Snapshots appear in a .zfs/snapshot/SNAPSHOT_NAME directory at each mountpoint and are accessible as a normal read-only directory hierarchy below there. OTOH, the send stream _is_ a blob. >Am I correct in assuming that one could: > > # zfs send -R snapshot | dd obs=3D10240 of=3D/dev/rst0 > >to archive it to tape instead of another [system:]drive? Yes. The output from zfs send is a stream of bytes that you can treat as you would any other stream of bytes. But this approach isn't recommended. --=20 Peter Jeremy --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEyedYACgkQ/opHv/APuIeXHgCgtDsDGKBTo9GmqRw+iE5FUpQb BHkAoJtSWoLcZoKxbLkL3pUNG/B5dJ8X =NogE -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 22:57:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7414B56D for ; Sat, 2 Mar 2013 22:57:14 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 12EDC7DF for ; Sat, 2 Mar 2013 22:57:13 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r22Mv5hI037309 for ; Sat, 2 Mar 2013 16:57:05 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Sat Mar 2 16:57:05 2013 Message-ID: <513283BC.5090606@denninger.net> Date: Sat, 02 Mar 2013 16:57:00 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> <20130302221446.GG286@server.rulingia.com> In-Reply-To: <20130302221446.GG286@server.rulingia.com> X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130302-1, 03/02/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 22:57:14 -0000 On 3/2/2013 4:14 PM, Peter Jeremy wrote: > On 2013-Mar-01 08:24:53 -0600, Karl Denninger wrot= e: >> If I then restore the base and snapshot, I get back to where I was whe= n >> the latest snapshot was taken. I don't need to keep the incremental >> snapshot for longer than it takes to zfs send it, so I can do: >> >> zfs snapshot pool/some-filesystem@unique-label >> zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-labe= l >> zfs destroy pool/some-filesystem@unique-label >> >> and that seems to work (and restore) just fine. > This gives you an incremental since the base snapshot - which will > probably grow in size over time. If you are storing the ZFS send > streams on (eg) tape, rather than receiving them, you probably still > want the "Towers of Hanoi" style backup hierarchy to control your > backup volume. It's also worth noting that whilst the stream will > contain the compression attributes of the filesystem(s) in it, the > actual data is the stream in uncompressed I noted that. The script I wrote to do this looks at the compression status in the filesystem and, if enabled, pipes the data stream through pbzip2 on the way to storage. The only problem with this presumption is that for database "data" filesystems the "best practices" say that you should set the recordsize to that of the underlying page size of the dbms (e.g. 8k for Postgresql) for best performance and NOT enable compression. Reality however is that the on-disk format of most database files is EXTREMELY compressible (often WELL better than 2:1), so I sacrifice there. I think the better option is to stuff a user parameter into the filesystem attribute table (which apparently I can do without boundary) telling the script whether or not to compress on output so it's not tied to the filesystem's compression setting. I'm quite-curious, in fact, as to whether the "best practices" really are in today's world. Specifically, for a CPU-laden machine with lots of compute power I wonder if enabling compression on the database filesystems and leaving the recordsize alone would be a net performance win due to the reduction in actual I/O volume. This assumes you have the CPU available, of course, but that has gotten cheaper much faster than I/O bandwidth has. >> This in turn means that keeping more than two incremental dumps offlin= e >> has little or no value; the second merely being taken to insure that >> there is always at least one that has been written to completion witho= ut >> error to apply on top of the base. > This is quite a critical point with this style of backup: The ZFS send > stream is not intended as an archive format. It includes error > detection but no error correction and any error in a stream renders > the whole stream unusable (you can't retrieve only part of a stream). > If you go this way, you probably want to wrap the stream in a FEC > container (eg based on ports/comms/libfec) and/or keep multiple copies.= That's no more of a problem than it is for a dump file saved on a disk though, is it? While restore can (putatively) read past errors on a tape, in reality if the storage is a disk and part of the file is unreadable the REST of that particular archive is unreadable. Skipping unreadable records does "sorta work" for tapes, but it rarely if ever does for storage onto a spinning device within the boundary of the impacted file. In practice I attempt to cover this by (1) saving the stream to local disk and then (2) rsync'ing the first disk to a second in the same cabinet. If the file I just wrote is unreadable I should discover it at (2), which hopefully is well before I actually need it in anger. Disk #2 then gets rotated out to an offsite vault on a regular schedule in case the building catches fire or similar. My exposure here is to time-related bitrot which is a non-zero risk but I can't scrub a disk that's sitting in a vault, so I don't know that there's a realistic means around this risk other than a full online "hotsite" that I can ship the snapshots to (which I don't have the necessary bandwidth or storage to cover.) If I change the backup media (currently UFS formatted) to ZFS formatted and dump directly there via a zfs send/receive I could run both drives as a mirror instead of rsync'ing from one to the other after the first copy is done, then detach the mirror to rotate the drive out and attach the other one, causing a resilver. That's fine EXCEPT if I have a controller go insane I now probably lose everything other than the offsite copy since everything is up for write during the snapshot operation. That ain't so good and that's a risk I've had turn into reality twice in 20 years. On the upside if the primary has an error on it I catch it when I try to resilver as that operation will fail since the entire data structure that's on-disk and written has to be traversed and the checksums should catch any silent corruption. If that happens I know I'm naked (other than the vault copy which I hope is good!) until I replace the backup drive with the error and re-copy everything. What I have trouble quantifying is which is the LARGER risk; I've yet to have a backup drive that is unreadable when I needed it, and I do test my restore capability pretty regularly, but twice in 20 years I've had active disk adapters in running machines destroy every write-mounted drive that was attached to them without warning. Both times the pucker factor went off the charts as soon as I realized what had happened as from an operational perspective it was pretty-much identical to a tornado or fire destroying the machine. > The "recommended" approach is to do zfs send | zfs recv and store a > replica of your pool (with whatever level of RAID that meets your > needs). This way, you immediately detect an error in the send stream > and can repeat the send. You then use scrub to verify (and recover) > the replica. I'm contemplating how to set that up in a way that works and has a reasonable associated operational profile for putting it into practice.=20 What I do now leaves the backup volumes unmounted except when actually being written to, which decreases (but does not completely eliminate) the risk of an insane controller scribbling on the backup volumes. =20 Setting read-only on the volumes doesn't help me at a filesystem level as the risk here is that of insane software and the days of a nice physical WRITE PROTECT switch on the front of a drive carrier are long in the past. I am also concerned about what happens as volume space grows beyond what can be saved on "X" devices and the problems associated with that. I've long since moved to using disk drives as a catalog for data streams rather than actual sequential media (e.g. tapes) due to the ridiculous imbalance in cost between high-capacity DLT-style drives and disks of equivalent storage, never mind transfer rates. One of the challenges that I see with ZFS is that it appears that a bogus block somewhere on a non-redundant medium may block future access to the entire pool. I'm not sure if that's actually the case or if you can read around the error, but if IS the case it's a serious problem.=20 UFS doesn't suffer from that; it will return errors on the file(s) impacted but if you avoid touching those you can read the rest of the pack and the data on it, assuming the failure is not total. ZFS doesn't really invalidate the entire pool on one unrecoverable error, does it? (The documentation is not at all clear if this is the case or not.) >> (Yes, I know, I've been a ZFS resister.... ;-)) > "Resistance is futile."=20 You know what happened to the Borg in the end, right? ;-) --=20 -- Karl Denninger /The Market Ticker =AE/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 23:13:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F00ABA17 for ; Sat, 2 Mar 2013 23:13:07 +0000 (UTC) (envelope-from prvs=1773e84f73=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7027D887 for ; Sat, 2 Mar 2013 23:13:06 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002492112.msg for ; Sat, 02 Mar 2013 23:13:06 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 02 Mar 2013 23:13:06 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=1773e84f73=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <2B3286B0A0354074824503C06E5D17D2@multiplay.co.uk> From: "Steven Hartland" To: "Karl Denninger" , References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> <20130302221446.GG286@server.rulingia.com> <513283BC.5090606@denninger.net> Subject: Re: Musings on ZFS Backup strategies Date: Sat, 2 Mar 2013 23:12:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:13:08 -0000 ----- Original Message ----- From: "Karl Denninger" > Reality however is that the on-disk format of most database files is > EXTREMELY compressible (often WELL better than 2:1), so I sacrifice > there. I think the better option is to stuff a user parameter into the > filesystem attribute table (which apparently I can do without boundary) > telling the script whether or not to compress on output so it's not tied > to the filesystem's compression setting. > > I'm quite-curious, in fact, as to whether the "best practices" really > are in today's world. Specifically, for a CPU-laden machine with lots > of compute power I wonder if enabling compression on the database > filesystems and leaving the recordsize alone would be a net performance > win due to the reduction in actual I/O volume. This assumes you have > the CPU available, of course, but that has gotten cheaper much faster > than I/O bandwidth has. We've been using ZFS compression on mysql filesystems for quite some time and have good success with it. It is dependent on the HW as you say though so you need to know where the bottleneck is in your system, cpu or disk. mysql 5.6 also added better recordsize support which could be interesting. Also be aware of the additional latency the compression can add. I'm also not 100% sure that the compression in ZFS scales beyond one core its been something I've meant to look in to / test but not got round to. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 2 23:15:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01189C62 for ; Sat, 2 Mar 2013 23:15:34 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id E08BF8BA for ; Sat, 2 Mar 2013 23:15:34 +0000 (UTC) To: freebsd-stable@freebsd.org Subject: Re: Musings on ZFS Backup strategies In-reply-to: <20130302221446.GG286@server.rulingia.com> References: <20130301165040.GA26251@anubis.morrow.me.uk> <20130301185912.GA27546@anubis.morrow.me.uk> <20130302221446.GG286@server.rulingia.com> Date: Sat, 02 Mar 2013 15:05:47 -0800 From: John Message-Id: <20130302230547.932DF15D@server.theusgroup.com> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:15:35 -0000 >The "recommended" approach is to do zfs send | zfs recv and store a >replica of your pool (with whatever level of RAID that meets your >needs). This way, you immediately detect an error in the send stream >and can repeat the send. You then use scrub to verify (and recover) >the replica. I do zfs send | zfs recv from several machines to a backup server in a different building. Each day an incremental send is done using the previous day's incremental send as the base. One reason for this approach is to minimize the amount of bandwidth required since one of the machines is across a T1. This technique requires keeping a record of the current base snapshot for each filesystem, and a system in place to keep from destroying the base snapshot. I learned the latter the hard way when a machine went down for several days, and when it came back up the script that destroys out-of-date snapshots deleted the incremental base snapshot. I'm running 9.1-stable with zpool features on my machines, and with this upgrade came zfs hold and zfs release. This allows you to lock a snapshot so it can't be destroyed until it's released. With this feature, I do the following for each filesystem: zfs send -i yesterdays_snapshot todays_snapshot | ssh backup_server zfs recv on success: zfs hold todays_snapshot zfs release yesterdays_snapshot ssh backup_server zfs hold todays_snapshot ssh backup_server zfs release yesterdays_snapshot update zfs_send_dates file with filesystem and snapshot name John Theus TheUsGroup.com