From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 00:54:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CACE73EA for ; Sun, 11 Aug 2013 00:54:08 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A072E289D for ; Sun, 11 Aug 2013 00:54:08 +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 4554211434; Sat, 10 Aug 2013 17:54:01 -0700 (PDT) Received: from [IPv6:fc00:970::913d:c915:ae7b:efbc] (unknown [IPv6:fc00:970::913d:c915:ae7b:efbc]) by chombo.houseloki.net (Postfix) with ESMTPSA id 54B73EC6; Sat, 10 Aug 2013 17:53:59 -0700 (PDT) Message-ID: <5206E0A9.1060005@bluerosetech.com> Date: Sat, 10 Aug 2013 17:54:01 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Patrick Dung Subject: Re: Discussing ideas or wish list References: <1376066075.81690.YahooMailNeo@web193503.mail.sg3.yahoo.com> <52056F38.7030701@bluerosetech.com> <1376108993.18621.YahooMailNeo@web193505.mail.sg3.yahoo.com> In-Reply-To: <1376108993.18621.YahooMailNeo@web193505.mail.sg3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 00:54:08 -0000 On 8/9/2013 9:29 PM, Patrick Dung wrote: > Yes, I can install lang/perl5.12. But in that case, I can't install > other perl /p5 pre-build packages (which depends on Perl 5.14) > provided by FreeBSD, due to dependency problem. Install them from ports and add the external dependencies from packages. Tools like portmaster even have options to automate this for you. From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 05:31:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E5E5F56 for ; Sun, 11 Aug 2013 05:31:34 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E17602324 for ; Sun, 11 Aug 2013 05:31:33 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq13so6327297pab.11 for ; Sat, 10 Aug 2013 22:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wSc4TgVsIo7ekqEpynikawGAhu9bEX1zBKagXe4qCdY=; b=QJA6ReZV2IE0Ezp4jXN/gy41+lARae/PCxa97ue7rCvMHy5AUCTjfxcdM7ueSbYqVn itcXNp29sv9KKhLAP9VwJG8526nh+fXL8zbTpXI0Z4ennx+1urSXB6ql2exdrHTpGyq1 vryT96N9hSm7utJm0mGnwQLpXzNHnfnGdzo5Jnf815R5j9+MlcKJpMxbdxmYW86/EJQb njyotY0qetLt/jKBE6goWGxcfSFiaEJCU0N9yvtzp9DroJnvsaIJwepQFcOEpC0Ls+lj Ng2S1m03RMBahKZp6mlniMNYioE5GNhn6MCp09BkxOj0AHZG5e222zPlrf4QXtF0VvQb SR4Q== MIME-Version: 1.0 X-Received: by 10.66.231.42 with SMTP id td10mr18230109pac.144.1376199093634; Sat, 10 Aug 2013 22:31:33 -0700 (PDT) Received: by 10.68.51.169 with HTTP; Sat, 10 Aug 2013 22:31:33 -0700 (PDT) Date: Sun, 11 Aug 2013 01:31:33 -0400 Message-ID: Subject: how to make a etc/rc.d start at boot time From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 05:31:34 -0000 I am creating a port for something that needs to start a daemon at boot time I have it so I can call onestart on it but XXX_enable="YES" in /etc/rc.conf fails to load it.... i.e. /usr/local/etc/rc.d/XXX onestart -- works XXX_enable="YES" -- fails From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 05:37:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6987D105 for ; Sun, 11 Aug 2013 05:37:52 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 50B4F234D for ; Sun, 11 Aug 2013 05:37:51 +0000 (UTC) Received: from [10.0.1.81] (c-24-6-17-162.hsd1.ca.comcast.net [24.6.17.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 5C6DB3981E; Sat, 10 Aug 2013 22:37:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1793.5\)) Subject: Re: how to make a etc/rc.d start at boot time From: Rui Paulo In-Reply-To: Date: Sat, 10 Aug 2013 22:37:31 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Aryeh Friedman X-Mailer: Apple Mail (2.1793.5) Cc: FreeBSD Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 05:37:52 -0000 On 10 Aug 2013, at 22:31, Aryeh Friedman wrote: > I am creating a port for something that needs to start a daemon at > boot time I have it so I can call onestart on it but XXX_enable="YES" > in /etc/rc.conf fails to load it.... i.e. > > > /usr/local/etc/rc.d/XXX onestart -- works > XXX_enable="YES" -- fails Please post your script. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 06:09:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57ADA459 for ; Sun, 11 Aug 2013 06:09:19 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32A3A247B for ; Sun, 11 Aug 2013 06:09:19 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id bg4so6363531pad.4 for ; Sat, 10 Aug 2013 23:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SuK+qsGaNHvuCgn0YcQKTKd+17LJpgCeC/ZoV+Efb8A=; b=zhUamaXXjnD2M7p9a6Q8Y88pcLc52auM6j8KSPbvAIgCUfUlSRofGrUY5docp67Xow kXduWBNFUG/X6eoKf4i02SI2PfYxVjRfrN0GnXLONy5PQcGFLDaYaA8N+mp49hDnRod8 nKlVIGP0jMEvqPG+sJeGkNYI8kpKCkeZkJHDAUHgN0H73wQ1OdEDKoDlvGq7htdN7pyj mM9Tzwc09BXVQOgzHS0+x+Emvf6dujEe2q9szswaifQpBs4+lWeAVOaNcNfllLqFN2dI aVHl05GHJ8pdE4x/1Q6MlwJsfgrNH4ShEpxtUofFZbaymbbzXsOCz8cxo1GgXEquX6Vn iMWA== MIME-Version: 1.0 X-Received: by 10.66.241.34 with SMTP id wf2mr18501832pac.111.1376201358895; Sat, 10 Aug 2013 23:09:18 -0700 (PDT) Received: by 10.68.51.169 with HTTP; Sat, 10 Aug 2013 23:09:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Aug 2013 02:09:18 -0400 Message-ID: Subject: Fwd: how to make a etc/rc.d start at boot time From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 06:09:19 -0000 ---------- Forwarded message ---------- From: Aryeh Friedman Date: Sun, Aug 11, 2013 at 2:07 AM Subject: Re: how to make a etc/rc.d start at boot time To: Rui Paulo #!/bin/sh # # Start/stop XXX at boot time # # Copyright (C) 2013 XXX . /etc/rc.subr name="XXX" start_cmd="${name}_start" stop_cmd=":" XXX_start() { echo "$name started." /usr/local/openjdk6/bin/java -cp \ /usr/local/share/XXX/XXX.jar \ XXX.yyy \ /usr/local/etc/XXX/YYY& } load_rc_config $name run_rc_command "$1" On Sun, Aug 11, 2013 at 1:37 AM, Rui Paulo wrote: > On 10 Aug 2013, at 22:31, Aryeh Friedman wrote: > >> I am creating a port for something that needs to start a daemon at >> boot time I have it so I can call onestart on it but XXX_enable="YES" >> in /etc/rc.conf fails to load it.... i.e. >> >> >> /usr/local/etc/rc.d/XXX onestart -- works >> XXX_enable="YES" -- fails > > Please post your script. > > -- > Rui Paulo > > > From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 06:47:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84F5E6F9 for ; Sun, 11 Aug 2013 06:47:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6B225E3 for ; Sun, 11 Aug 2013 06:47:12 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7B6lBOf011438; Sat, 10 Aug 2013 23:47:11 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <5207336F.5070307@rawbw.com> Date: Sat, 10 Aug 2013 23:47:11 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Patrick Dung Subject: Re: Discussing ideas or wish list References: <1376066075.81690.YahooMailNeo@web193503.mail.sg3.yahoo.com> In-Reply-To: <1376066075.81690.YahooMailNeo@web193503.mail.sg3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 06:47:12 -0000 On 08/09/2013 09:34, Patrick Dung wrote: > Some (crazy?) ideas: > a) Is it possible to install multiple Perl versions in the same server? > Each third party Perl packages would linked to the corresponding Perl versions? > Users have to update /usr/bin/perl to link to the desired Perl version (or using wrapper mechanism like /etc/mail/mail.conf). Being able to create multiple unique environments on the same host is very beneficial. I believe Oracle Solaris on ZFS is able to install individual packages into separate zones, and ZFS can share certain zones between each other. Manipulating sharing rules allows creation of exactly this: various unique set of packages in top-level zones. So for example, perl and all its dependent packages can be installed multiple times in multiple versions in different ZFS zones on top of shared dependency packages. Unfortunately, FreeBSD version of ZFS lacks zones. Yuri From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 12:12:56 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D3BA4FDB; Sun, 11 Aug 2013 12:12:56 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89241227D; Sun, 11 Aug 2013 12:12:56 +0000 (UTC) Received: from localhost.localdomain (pool-173-52-119-53.nycmny.fios.verizon.net [173.52.119.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id BCA4B33EBEC; Sun, 11 Aug 2013 12:12:53 +0000 (UTC) From: Richard Yao To: hackers@FreeBSD.org Subject: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 Date: Sun, 11 Aug 2013 08:12:25 -0400 Message-Id: <1376223145-81081-1-git-send-email-ryao@gentoo.org> X-Mailer: git-send-email 1.8.1.5 Cc: Richard Yao , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 12:12:56 -0000 Signed-off-by: Richard Yao --- sys/cam/ata/ata_da.c | 24 ++++++++++++++++++++++++ sys/cam/scsi/scsi_da.c | 24 ++++++++++++++++++++++++ 2 files changed, 48 insertions(+) diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c index f201231..b7f293d 100644 --- a/sys/cam/ata/ata_da.c +++ b/sys/cam/ata/ata_da.c @@ -349,6 +349,14 @@ static struct ada_quirk_entry ada_quirk_table[] = }, { /* + * Intel X25-M Series SSDs + * 4k optimised & trim only works in 4k requests + 4k aligned + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, + /*quirks*/ADA_Q_4K + }, + { + /* * Kingston E100 Series SSDs * 4k optimised & trim only works in 4k requests + 4k aligned */ @@ -365,6 +373,22 @@ static struct ada_quirk_entry ada_quirk_table[] = }, { /* + * Marvell SSD (entry taken from Open Solaris) + * 4k optimised & trim only works in 4k requests + 4k aligned + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, + /*quirks*/ADA_Q_4K + }, + { + /* + * OCZ Agility 2 SSDs + * 4k optimised & trim only works in 4k requests + 4k aligned + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, + /*quirks*/ADA_Q_4K + }, + { + /* * OCZ Agility 3 SSDs * 4k optimised & trim only works in 4k requests + 4k aligned */ diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c index 617afbd..df895be 100644 --- a/sys/cam/scsi/scsi_da.c +++ b/sys/cam/scsi/scsi_da.c @@ -1008,6 +1008,14 @@ static struct da_quirk_entry da_quirk_table[] = }, { /* + * Intel X25-M Series SSDs + * 4k optimised & trim only works in 4k requests + 4k aligned + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, + /*quirks*/ADA_Q_4K + }, + { + /* * Kingston E100 Series SSDs * 4k optimised & trim only works in 4k requests + 4k aligned */ @@ -1024,6 +1032,22 @@ static struct da_quirk_entry da_quirk_table[] = }, { /* + * Marvell SSD (entry taken from Open Solaris) + * 4k optimised & trim only works in 4k requests + 4k aligned + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, + /*quirks*/ADA_Q_4K + }, + { + /* + * OCZ Agility 2 SSDs + * 4k optimised & trim only works in 4k requests + 4k aligned + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, + /*quirks*/ADA_Q_4K + }, + { + /* * OCZ Agility 3 SSDs * 4k optimised & trim only works in 4k requests + 4k aligned */ -- 1.8.1.5 From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 11 13:48:39 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8D27F22; Sun, 11 Aug 2013 13:48:39 +0000 (UTC) (envelope-from prvs=1935f40c3d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DFC7262F; Sun, 11 Aug 2013 13:48:38 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005441845.msg; Sun, 11 Aug 2013 14:48:30 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 11 Aug 2013 14:48:30 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1935f40c3d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <8E8C51CCA3474B7A9E2C477D4BCEBB04@multiplay.co.uk> From: "Steven Hartland" To: "Richard Yao" , References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 Date: Sun, 11 Aug 2013 14:48:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Richard Yao , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 13:48:40 -0000 Thanks Richard I'll commit these when I get in the office next week. Regards Steve ----- Original Message ----- From: "Richard Yao" To: Cc: "Richard Yao" ; "Eitan Adler" Sent: Sunday, August 11, 2013 1:12 PM Subject: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 > Signed-off-by: Richard Yao > --- > sys/cam/ata/ata_da.c | 24 ++++++++++++++++++++++++ > sys/cam/scsi/scsi_da.c | 24 ++++++++++++++++++++++++ > 2 files changed, 48 insertions(+) > > diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c > index f201231..b7f293d 100644 > --- a/sys/cam/ata/ata_da.c > +++ b/sys/cam/ata/ata_da.c > @@ -349,6 +349,14 @@ static struct ada_quirk_entry ada_quirk_table[] = > }, > { > /* > + * Intel X25-M Series SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * Kingston E100 Series SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > @@ -365,6 +373,22 @@ static struct ada_quirk_entry ada_quirk_table[] = > }, > { > /* > + * Marvell SSD (entry taken from Open Solaris) > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > + * OCZ Agility 2 SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * OCZ Agility 3 SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c > index 617afbd..df895be 100644 > --- a/sys/cam/scsi/scsi_da.c > +++ b/sys/cam/scsi/scsi_da.c > @@ -1008,6 +1008,14 @@ static struct da_quirk_entry da_quirk_table[] = > }, > { > /* > + * Intel X25-M Series SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * Kingston E100 Series SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > @@ -1024,6 +1032,22 @@ static struct da_quirk_entry da_quirk_table[] = > }, > { > /* > + * Marvell SSD (entry taken from Open Solaris) > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > + * OCZ Agility 2 SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * OCZ Agility 3 SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > -- > 1.8.1.5 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > ================================================ 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-hackers@FreeBSD.ORG Sun Aug 11 19:04:05 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE872639; Sun, 11 Aug 2013 19:04:05 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7D0D2311; Sun, 11 Aug 2013 19:04:05 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-119-53.nycmny.fios.verizon.net [173.52.119.53]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id A733C33E72B; Sun, 11 Aug 2013 19:04:03 +0000 (UTC) Message-ID: <5207E00F.4000400@gentoo.org> Date: Sun, 11 Aug 2013 15:03:43 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130714 Thunderbird/17.0.7 MIME-Version: 1.0 To: Steven Hartland Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> <8E8C51CCA3474B7A9E2C477D4BCEBB04@multiplay.co.uk> In-Reply-To: <8E8C51CCA3474B7A9E2C477D4BCEBB04@multiplay.co.uk> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GQJMUOIRBJKJJPJXVXRQ" Cc: hackers@FreeBSD.org, Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 19:04:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GQJMUOIRBJKJJPJXVXRQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there any possibility that these quirks could be added to the upcoming 9.2 release? Pools composed of affected disks will suffer from performance issues until they are reformatted with the correct block size. In addition, a certain benchmarking site, whose benchmarks are often fodder for trolls, uses the Intel X25-M in its benchmarks. Adding the quirk to 9.2 would eliminate an unfair handicap on FreeBSD from their next set of benchmarks= =2E On 08/11/2013 09:48 AM, Steven Hartland wrote: > Thanks Richard I'll commit these when I get in the office next week. >=20 > Regards > Steve > ----- Original Message ----- From: "Richard Yao" > To: > Cc: "Richard Yao" ; "Eitan Adler" = > Sent: Sunday, August 11, 2013 1:12 PM > Subject: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ= > Agility 2 >=20 >=20 >> Signed-off-by: Richard Yao >> --- >> sys/cam/ata/ata_da.c | 24 ++++++++++++++++++++++++ >> sys/cam/scsi/scsi_da.c | 24 ++++++++++++++++++++++++ >> 2 files changed, 48 insertions(+) >> >> diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c >> index f201231..b7f293d 100644 >> --- a/sys/cam/ata/ata_da.c >> +++ b/sys/cam/ata/ata_da.c >> @@ -349,6 +349,14 @@ static struct ada_quirk_entry ada_quirk_table[] =3D= >> }, >> { >> /* >> + * Intel X25-M Series SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * Kingston E100 Series SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> @@ -365,6 +373,22 @@ static struct ada_quirk_entry ada_quirk_table[] =3D= >> }, >> { >> /* >> + * Marvell SSD (entry taken from Open Solaris) >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> + * OCZ Agility 2 SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * OCZ Agility 3 SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c >> index 617afbd..df895be 100644 >> --- a/sys/cam/scsi/scsi_da.c >> +++ b/sys/cam/scsi/scsi_da.c >> @@ -1008,6 +1008,14 @@ static struct da_quirk_entry da_quirk_table[] =3D= >> }, >> { >> /* >> + * Intel X25-M Series SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * Kingston E100 Series SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> @@ -1024,6 +1032,22 @@ static struct da_quirk_entry da_quirk_table[] =3D= >> }, >> { >> /* >> + * Marvell SSD (entry taken from Open Solaris) >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> + * OCZ Agility 2 SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * OCZ Agility 3 SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> --=20 >> 1.8.1.5 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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. >=20 ------enig2GQJMUOIRBJKJJPJXVXRQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSB+ARAAoJECDuEZm+6ExkM7YP/A8Ox724c2XYnHs8I/BcaN0E uXyucHaUO+nvJUFf0iac5hE8zavKk8TZkLSsAxE29de5U6j5kOBs1uGuI8ypDD1/ bDNpwfzMStu87W/OOYC+xyeqNBJsf/og8D1DLpj/yz7expSVyexplvwg1TF0TFqx ZhhsXsaodWY10mWfYA9Fm3L0omhHdgDe0bQvOAcWSapLhs0XNKZubFOf4c78hpoj dZzbak6xKCnrmQXIYBo3n3b7XKapnDqL530XDmkf9ifGtstXoWeQ21ClEGynP+wr Kj30Abb4ADi7Ty2qdi44Mrh/kNP1Nv1OgwgODts5CtfwDmDySWscQotaXnje1bSo s16xCnrAxDaaOME5m7AAYmx5SFZ3R/Xxc+4cZLrzbTIWl56f1Z0s0smISTL+eMi0 YA+Wi0ApW6zVAhnBabKizGc01Pbr7j2DddbDARSv2z9zNc7hWhW+feoSg/6IcVlw 8H0SPJeD/x/wouX8yRBS7lxTVLKNHfHpHESQyptsjmdXNWGuPyvWi4PptsqpUWI0 LP7M59Wyt6jnY95MUbxhdzGQX1Kv9WFy16fRkmBEKu6LIV2Me2EX7F2yAWXfKiWj bm16m9TP40TJY62paX/gyv/gyFmjUHwg5HEvlanxb1DY4ynyWho2ngHegWwviINk 8f1r1SCXTju5Y4SPQsUg =C09f -----END PGP SIGNATURE----- ------enig2GQJMUOIRBJKJJPJXVXRQ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 12 00:50:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 71F24D20 for ; Mon, 12 Aug 2013 00:50:13 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DD972F72 for ; Mon, 12 Aug 2013 00:50:13 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id g10so2716519pdj.30 for ; Sun, 11 Aug 2013 17:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=R9J5DNfdXzS4Hvc7Fn8FB6ir7jkXBVg7CasXVIC4ijE=; b=QTeC0qnvM55sViD+APeJrETwPy7CJA5Gruwv8/5PTyAO+jGtpCD1cZnHtIDYxiPAnn TfO3ICAUUWvr9pQbwg6FscFjd51T7/Tsft46mcwpEwTNzMvLPmjwFl37guxTNnHNH/V8 FKcZncdPLg7xcyJ8G/vQk6piu9g4lnwFrYNnLpQWzsdUwlNnNUG/LDTb4gnt0PHLSZSq 9g6ZIrX8HIbxhYQd5hBY5UHZXAyO/vTbjCbwsHu9pcC4qv19kXCzuughH8F0Mo2PX9Ew x86OUmnWbP5Xx04UYyMtiBKxxWXgFaf12r3PHxi7TWmHLtSrI0oqPYQH1ofqClu9HYj7 XTEQ== MIME-Version: 1.0 X-Received: by 10.66.233.37 with SMTP id tt5mr10983463pac.95.1376268613021; Sun, 11 Aug 2013 17:50:13 -0700 (PDT) Received: by 10.68.51.169 with HTTP; Sun, 11 Aug 2013 17:50:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Aug 2013 20:50:12 -0400 Message-ID: Subject: min. sys. requirements From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 00:50:13 -0000 Where would I find documentation on the minimum system requirements for 9.2 (not 9.1) and 10-CURRENT? I also need to know the requirements for the ports I am installing the top level ones are: devel/aegis devel/cook devel/fhist devel/tardy devel/thistest (forth coming as me as the maintainer) editors/vim emulator/XXX (forth coming as me as the maintainer -- name withheld til trademarks are applied for) java/openjdk6 secuirty/sudo www/tomcat7 Reason for asking is I am making a VM image for bhyve(4) and want to know how much ram, cpu and disk to allocate for the VM From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 12 15:25:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7980056F for ; Mon, 12 Aug 2013 15:25:38 +0000 (UTC) (envelope-from joris.dedieu@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F346C2693 for ; Mon, 12 Aug 2013 15:25:37 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id mf11so4867667lab.1 for ; Mon, 12 Aug 2013 08:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2QsH1yC1+3dwE5wdVh+fODoJ+MI+Uxuexrhj31/n/KY=; b=TLSaz1amk8U9AcWotKUw2DsXKnj1GmLNdMelhmAWfAzqDs4XZP+rJL6gqbgPcuKvOA /lAseLGGDzn1EdmWRaW4Yweu80oaZEPh26I8kC0iR/ZxajHLe/woAoxXRoxjAdXPhdjZ 1DgOIwL76YYswA+GxXqnhmDCZu0fjSh/HGDMixBRzpWKIQINc2ZjBNPDpvzkeUzlf9/v tyM3cgFN0aouaH7VGUsxU3q64/qdj6wSRDGaavK6g1NE1Hmj464Da7phQgLF2RPt7oCU U5j9J0LXKcYa33gvEqFEPHvnXOgweXXy88fpjwU2PcbkxIH+R9b1ODQQj8gU+FJuxk12 gxXw== MIME-Version: 1.0 X-Received: by 10.112.211.136 with SMTP id nc8mr6553191lbc.80.1376321135985; Mon, 12 Aug 2013 08:25:35 -0700 (PDT) Received: by 10.114.22.99 with HTTP; Mon, 12 Aug 2013 08:25:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Aug 2013 17:25:35 +0200 Message-ID: Subject: Re: how to make a etc/rc.d start at boot time From: joris dedieu To: Aryeh Friedman Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:25:38 -0000 2013/8/11 Aryeh Friedman : > ---------- Forwarded message ---------- > From: Aryeh Friedman > Date: Sun, Aug 11, 2013 at 2:07 AM > Subject: Re: how to make a etc/rc.d start at boot time > To: Rui Paulo > > > #!/bin/sh > # > # Start/stop XXX at boot time > # > # Copyright (C) 2013 XXX > > . /etc/rc.subr > > name="XXX" rcvar=XXX_enable pidfile="/var/run/rXXX.pid" > start_cmd="${name}_start" > stop_cmd=":" > > XXX_start() { > echo "$name started." > /usr/local/openjdk6/bin/java -cp \ > /usr/local/share/XXX/XXX.jar \ > XXX.yyy \ > /usr/local/etc/XXX/YYY& > } You don't need to overwrite start_cmd java_command="%%LOCALBASE%%/bin/java" XXX_classpath="/usr/local/share/XXX/XXX.jar" XXX_start_cmd="${java_command} -cp ${XXX_classpath} ..." command="/usr/sbin/daemon" flags="-p ${pidfile} ${XXX_start_cmd}" > > load_rc_config $name This have to come earlier in the script See : http://www.freebsd.org/doc/en/books/porters-handbook/rc-scripts.html Joris > > run_rc_command "$1" > > > On Sun, Aug 11, 2013 at 1:37 AM, Rui Paulo wrote: >> On 10 Aug 2013, at 22:31, Aryeh Friedman wrote: >> >>> I am creating a port for something that needs to start a daemon at >>> boot time I have it so I can call onestart on it but XXX_enable="YES" >>> in /etc/rc.conf fails to load it.... i.e. >>> >>> >>> /usr/local/etc/rc.d/XXX onestart -- works >>> XXX_enable="YES" -- fails >> >> Please post your script. >> >> -- >> Rui Paulo >> >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 13 21:21:09 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DFDBAF86 for ; Tue, 13 Aug 2013 21:21:09 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id CAB0E2659 for ; Tue, 13 Aug 2013 21:21:09 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7DLL3NR075248 for ; Tue, 13 Aug 2013 14:21:03 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <520AA33E.1050602@rawbw.com> Date: Tue, 13 Aug 2013 14:21:02 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Kernel DDB doesn't work in VM ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:21:09 -0000 I have kernel configured with options KDB and DDB. But when kernel panic occurs while running as VBox VM, VBox takes over and says: "A critical error occurred while running the virtual machine", etc. It doesn't drop into DDB. Pressing Ok closes VM, pressing "Ignore" leaves it in hung state. sysctl debug.kdb.enter=1 also causes the above behavior as if panic has occurred. Is it possible to make DDB kick in while running as VM? Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 14 02:02:36 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5E1ABC68; Wed, 14 Aug 2013 02:02:36 +0000 (UTC) (envelope-from prvs=19381d5a45=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 672C825B8; Wed, 14 Aug 2013 02:02:35 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005485496.msg; Wed, 14 Aug 2013 03:02:32 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 14 Aug 2013 03:02:32 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19381d5a45=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Richard Yao" , References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 Date: Wed, 14 Aug 2013 03:02:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Richard Yao , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 02:02:36 -0000 Could you provide the output from camcontrol identify for these disks I want to just double check the formatting before commiting as I don't have these disks here in labs. Regards Steve ----- Original Message ----- From: "Richard Yao" To: Cc: "Richard Yao" ; "Eitan Adler" Sent: Sunday, August 11, 2013 1:12 PM Subject: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 > Signed-off-by: Richard Yao > --- > sys/cam/ata/ata_da.c | 24 ++++++++++++++++++++++++ > sys/cam/scsi/scsi_da.c | 24 ++++++++++++++++++++++++ > 2 files changed, 48 insertions(+) > > diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c > index f201231..b7f293d 100644 > --- a/sys/cam/ata/ata_da.c > +++ b/sys/cam/ata/ata_da.c > @@ -349,6 +349,14 @@ static struct ada_quirk_entry ada_quirk_table[] = > }, > { > /* > + * Intel X25-M Series SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * Kingston E100 Series SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > @@ -365,6 +373,22 @@ static struct ada_quirk_entry ada_quirk_table[] = > }, > { > /* > + * Marvell SSD (entry taken from Open Solaris) > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > + * OCZ Agility 2 SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * OCZ Agility 3 SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c > index 617afbd..df895be 100644 > --- a/sys/cam/scsi/scsi_da.c > +++ b/sys/cam/scsi/scsi_da.c > @@ -1008,6 +1008,14 @@ static struct da_quirk_entry da_quirk_table[] = > }, > { > /* > + * Intel X25-M Series SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * Kingston E100 Series SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > @@ -1024,6 +1032,22 @@ static struct da_quirk_entry da_quirk_table[] = > }, > { > /* > + * Marvell SSD (entry taken from Open Solaris) > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > + * OCZ Agility 2 SSDs > + * 4k optimised & trim only works in 4k requests + 4k aligned > + */ > + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, > + /*quirks*/ADA_Q_4K > + }, > + { > + /* > * OCZ Agility 3 SSDs > * 4k optimised & trim only works in 4k requests + 4k aligned > */ > -- > 1.8.1.5 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > ================================================ 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-hackers@FreeBSD.ORG Wed Aug 14 04:12:25 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 35A238D3; Wed, 14 Aug 2013 04:12:25 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC36B2C30; Wed, 14 Aug 2013 04:12:24 +0000 (UTC) Received: from delphij-macbook.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 403B4AFB0; Tue, 13 Aug 2013 21:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1376453544; bh=+9IT5qv5z7QxKesaHqLZ+NsCNegMhct/HN8SbRWPibM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=uziASXo2eIuNPAiAFCr556E7BQ7FlJolzDQEvFCnug3YEglZNYIXbmXjnpb9mPOk/ VX3k+8WFPpcEIYzQZu3XrF0WCIEM7Wa9ce8ZpMP6a4McbVhRkARhidFDAJ/tcjOU0U LI2mntZDAcfcRPPZocXBF4GaZkrJvV13H6CrE5/g= Message-ID: <520B03A7.30406@delphij.net> Date: Tue, 13 Aug 2013 21:12:23 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Richard Yao Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> <8E8C51CCA3474B7A9E2C477D4BCEBB04@multiplay.co.uk> <5207E00F.4000400@gentoo.org> In-Reply-To: <5207E00F.4000400@gentoo.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eitan Adler , hackers@FreeBSD.org, Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 04:12:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/11/13 12:03 PM, Richard Yao wrote: > Is there any possibility that these quirks could be added to the > upcoming 9.2 release? I think so but we need to act fast. > Pools composed of affected disks will suffer from performance > issues until they are reformatted with the correct block size. In > addition, a certain benchmarking site, whose benchmarks are often > fodder for trolls, uses the Intel X25-M in its benchmarks. Adding > the quirk to 9.2 would eliminate an unfair handicap on FreeBSD from > their next set of benchmarks. Actually I'm not 100% sure here: the current FreeBSD ZFS code does not handle stripesize at all, and thus if you create a pool with the patch, they will still be ashift=9. Justin (gibbs@) have a patchset to address this by the way, but since it's not yet in HEAD I wouldn't expect it be incorporated in 9.2... Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJSCwOnAAoJEG80Jeu8UPuz4o8H/3D58PVp5lBJ9wpQ/+4YSDAF LdzbhSg5FoRLLgEFKd6q4sbkZglBR5lImWcL/zhGa1KHiq3G6iCstjhfJDQzLnsd tNYnZ9tBCd4AeD/TIFvuLpOJckeXL1TPBSDjXj0xt9rcMCviULma7cr95cswISMD ahK1Io6mVbiGQrCgRmHrUBhnuZfou5nOxPi45l0Lfqq32iJFfgHfmDiCr0mCKkuU sufMeRWS/tjMkl8sVZxP7qncGxbhzVueQeQQ6eJkyv5EQCES6QMZM8xFXfeI//Z4 bDzD37rvt/HRlhPpex0UcpmbYY9dGJJrOALEAPfexMcc++gvLCmYqNfj0ypDj90= =JfHW -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 14 04:15:46 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF4989D9; Wed, 14 Aug 2013 04:15:46 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B6572C49; Wed, 14 Aug 2013 04:15:46 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ij15so4721815vcb.16 for ; Tue, 13 Aug 2013 21:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QGwXLmkOOxuNtMFzHWZ6ZVV0cB0LwBiFDhsAqjHLxlY=; b=n3RWNcCsMXf4c7QI8JY++teDHU6YzTVpYqnk8O45j7DN9TB0Ato7FoQ+tvRDj17cBz qYV5krSkSxn4b1MnbA5H7pD7cW7+7OEbsn5zFhP+0tkKo/oBG7BxlXGzF6n+lT6r4hy7 q0wy/oUUYUrkjg9zlfFMG1+RBYwHx2x1R2YHXbXQfaySNWXYCSWR781cEzaQIRYTjDFd VH7BkK3ldHROsPj95SS8BwfQnKUlab2qmVZfu3El95hetUYKWIWAiHHspvgfxbM3JYGh hOz3F2ckqh0zpfbOszSl3SAAE01HZw9O1qF4KyDLwABfTmi/BvdKP62wbK3UUSLWWzHO y61Q== MIME-Version: 1.0 X-Received: by 10.220.10.194 with SMTP id q2mr7391834vcq.2.1376453745681; Tue, 13 Aug 2013 21:15:45 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.68.205 with HTTP; Tue, 13 Aug 2013 21:15:45 -0700 (PDT) In-Reply-To: References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> Date: Tue, 13 Aug 2013 21:15:45 -0700 X-Google-Sender-Auth: Mrs3ZE8hC-kFLdC-yYblmuuBxRs Message-ID: Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 From: Artem Belevich To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Richard Yao , hackers@freebsd.org, Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 04:15:46 -0000 On Tue, Aug 13, 2013 at 7:02 PM, Steven Hartland wrote: > Could you provide the output from camcontrol identify for these > disks I want to just double check the formatting before commiting as I > don't have these disks here in labs. > > Regards > Steve > Here's one for X25-M G2 and Intel 320: $ camcontrol identify ada0 pass8: ATA-7 SATA 2.x device pass8: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-7 SATA 2.x device model INTEL SSDSA2M080G2GC firmware revision 2CV102G9 serial number xxxxxxxxxxx WWN xxxxxxxxxxx cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 156301488 sectors LBA48 supported 156301488 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) no $ camcontrol identify ada1 pass9: ATA-8 SATA 2.x device pass9: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model INTEL SSDSA2CW120G3 firmware revision 4PC10302 serial number CVPR119200FB120LGN WWN 500151795956733b cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 234441648 sectors LBA48 supported 234441648 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 14 08:33:38 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EA03889C; Wed, 14 Aug 2013 08:33:38 +0000 (UTC) (envelope-from prvs=19381d5a45=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F3982747; Wed, 14 Aug 2013 08:33:38 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005488548.msg; Wed, 14 Aug 2013 09:33:29 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 14 Aug 2013 09:33:29 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19381d5a45=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: , "Richard Yao" References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> <8E8C51CCA3474B7A9E2C477D4BCEBB04@multiplay.co.uk> <5207E00F.4000400@gentoo.org> <520B03A7.30406@delphij.net> Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 Date: Wed, 14 Aug 2013 09:33:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@FreeBSD.org, Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 08:33:39 -0000 ----- Original Message ----- From: "Xin Li" > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 8/11/13 12:03 PM, Richard Yao wrote: >> Is there any possibility that these quirks could be added to the >> upcoming 9.2 release? > > I think so but we need to act fast. > >> Pools composed of affected disks will suffer from performance >> issues until they are reformatted with the correct block size. In >> addition, a certain benchmarking site, whose benchmarks are often >> fodder for trolls, uses the Intel X25-M in its benchmarks. Adding >> the quirk to 9.2 would eliminate an unfair handicap on FreeBSD from >> their next set of benchmarks. > > Actually I'm not 100% sure here: the current FreeBSD ZFS code does not > handle stripesize at all, and thus if you create a pool with the > patch, they will still be ashift=9. Justin (gibbs@) have a patchset > to address this by the way, but since it's not yet in HEAD I wouldn't > expect it be incorporated in 9.2... Indeed, there is nothing which really makes proper use of QUIRKS that I'm aware of and ZFS definitely doesn't. There's a number of patches around which correct that, I've one here too, but none as yet are a total solution to the ashift issue. 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-hackers@FreeBSD.ORG Wed Aug 14 17:17:35 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7897B1A; Wed, 14 Aug 2013 17:17:35 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77070288B; Wed, 14 Aug 2013 17:17:35 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-119-53.nycmny.fios.verizon.net [173.52.119.53]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 94B8F33EA97; Wed, 14 Aug 2013 17:17:28 +0000 (UTC) Message-ID: <520BBB91.4010209@gentoo.org> Date: Wed, 14 Aug 2013 13:17:05 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130714 Thunderbird/17.0.7 MIME-Version: 1.0 To: Steven Hartland Subject: Re: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ Agility 2 References: <1376223145-81081-1-git-send-email-ryao@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2JGBTUTDXAIXHUGNSGMVV" Cc: hackers@FreeBSD.org, Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:17:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JGBTUTDXAIXHUGNSGMVV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I neglected to include the CC list on the previous email that I sent, so here is a reproduction: I am afraid that is not possible. I extracted the "MARVELL SD88SA02" entry from Open Solaris. The OCZ Agility 2 entry was provided by another Gentoo developer using a tool that performed an inquiry query and extracted the exact 24 bytes in the combined vendor/product identification fields. The same was done for the X25-M. I actually do own one of those and could get FreeBSD running on that machine, but Artem Belevich has already responded with that information. On 08/13/2013 10:02 PM, Steven Hartland wrote: > Could you provide the output from camcontrol identify for these > disks I want to just double check the formatting before commiting as I > don't have these disks here in labs. >=20 > Regards > Steve >=20 > ----- Original Message ----- From: "Richard Yao" > To: > Cc: "Richard Yao" ; "Eitan Adler" = > Sent: Sunday, August 11, 2013 1:12 PM > Subject: [PATCH] Add 4K QUIRK for Intel X25-M, MARVELL SD88SA02 and OCZ= > Agility 2 >=20 >=20 >> Signed-off-by: Richard Yao >> --- >> sys/cam/ata/ata_da.c | 24 ++++++++++++++++++++++++ >> sys/cam/scsi/scsi_da.c | 24 ++++++++++++++++++++++++ >> 2 files changed, 48 insertions(+) >> >> diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c >> index f201231..b7f293d 100644 >> --- a/sys/cam/ata/ata_da.c >> +++ b/sys/cam/ata/ata_da.c >> @@ -349,6 +349,14 @@ static struct ada_quirk_entry ada_quirk_table[] =3D= >> }, >> { >> /* >> + * Intel X25-M Series SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * Kingston E100 Series SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> @@ -365,6 +373,22 @@ static struct ada_quirk_entry ada_quirk_table[] =3D= >> }, >> { >> /* >> + * Marvell SSD (entry taken from Open Solaris) >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> + * OCZ Agility 2 SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * OCZ Agility 3 SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c >> index 617afbd..df895be 100644 >> --- a/sys/cam/scsi/scsi_da.c >> +++ b/sys/cam/scsi/scsi_da.c >> @@ -1008,6 +1008,14 @@ static struct da_quirk_entry da_quirk_table[] =3D= >> }, >> { >> /* >> + * Intel X25-M Series SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSA2M*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * Kingston E100 Series SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> @@ -1024,6 +1032,22 @@ static struct da_quirk_entry da_quirk_table[] =3D= >> }, >> { >> /* >> + * Marvell SSD (entry taken from Open Solaris) >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "MARVELL SD88SA02*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> + * OCZ Agility 2 SSDs >> + * 4k optimised & trim only works in 4k requests + 4k aligned >> + */ >> + { T_DIRECT, SIP_MEDIA_FIXED, "*", "OCZ-AGILITY2*", "*" }, >> + /*quirks*/ADA_Q_4K >> + }, >> + { >> + /* >> * OCZ Agility 3 SSDs >> * 4k optimised & trim only works in 4k requests + 4k aligned >> */ >> --=20 >> 1.8.1.5 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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. >=20 ------enig2JGBTUTDXAIXHUGNSGMVV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSC7uUAAoJECDuEZm+6Exk8E8P/R8NdfZmkONsOO7xIaryrWGT P3KHdHFS5iTZvqfEjnSkvpH/8irlBY2L6ld9MifP/yZyKZxb+yIDNCIsettZG8Bu pgpVebGeNmumzQAR/NY3NNyZxnYBjP2nhZaVJVIAu0I/WRrtgCIiHfGQruQ9Olp+ UxBU3qdaZG//FpFq9uWugjVG/iag2R6HgZfHnPqygRHB6yqj83xVSxVT8K32KkIe vGus6wFr0H54qWIfNnbYQlKrSVKd8OPo+/XyOByKWgCys+609IyX/xiVWjHR2/ey 4/Ax11EpRBGv+tMp8yVmL0OL+pBlPS2MtCCkkaHd6Va63TtwNxW5RJIygD8gD5cO FOmHgXL4diX6NXU9xqBe5+yido8WPQ5cMz9dQPNVpdswfjnv3DLa+orSItaplAbi TZxN2C9h7TO/r9u8FVZwt7+MQqhP7JUZj0oG4/g+xrQoORTdGikmZroQ8zaETeaC Lr3YN4y8dpf4tLsPBG5PBVVvr0TVharxEBJ0edlzyGqpTZprJUT+9YDvsxKdVuDU NsaKrChHyC1iKC1SYjhm1GSwcKzTdE4ZhEnRlPSLFM3wN0Zs/Gb8awyO6Hq3huNr fqFoFiTmNug7oSkZGV/8kJWmbFYqAXtHYNFC168EhfMq7rVKGRZ/UiELb2QxWWO/ bWVa2DPNQQJ2/V9W7wf4 =gWSA -----END PGP SIGNATURE----- ------enig2JGBTUTDXAIXHUGNSGMVV-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 14 18:41:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E19D485F; Wed, 14 Aug 2013 18:41:46 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F1952DEB; Wed, 14 Aug 2013 18:41:45 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.89,878,1367989200"; d="scan'208";a="39998222" Message-ID: <520BCF67.2070109@vangyzen.net> Date: Wed, 14 Aug 2013 13:41:43 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130702 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Brooks Davis , marcel@FreeBSD.org Subject: [PATCH] Add flag to makefs to require specfile entries to exist Content-Type: multipart/mixed; boundary="------------040609050209020303070807" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:41:47 -0000 --------------040609050209020303070807 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit The attached patch adds a -X flag to makefs: If a regular file listed in the specfile does not exist in the file system, and the entry is not marked optional, abort creation of the image. Without this flag, the image would contain a zero-length file in this case. This is very handy when the specfile is the absolute authority for the contents of the image. It fails early and loudly, instead of causing late and sometimes obscure run-time errors. I checked NetBSD-current; the -X flag is available there. Would someone like to commit it for me? Eric --------------040609050209020303070807 Content-Type: text/plain; charset="ISO-8859-1"; name="makefs-X-head.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="makefs-X-head.patch" commit 4f90b5ed516eab57c951162cfdc29d0da0ae7495 Author: Eric van Gyzen Date: Wed Aug 14 13:25:55 2013 -0500 Add a -X flag to makefs If a regular file listed in the specfile does not exist in the file system, and the entry is not marked optional, abort creation of the image. Without this flag, the image would contain a zero-length file in this case. Obtained from: Dell, Inc. diff --git a/usr.sbin/makefs/makefs.8 b/usr.sbin/makefs/makefs.8 index 4d81e45..776933d 100644 --- a/usr.sbin/makefs/makefs.8 +++ b/usr.sbin/makefs/makefs.8 @@ -43,7 +43,7 @@ .Nd create a file system image from a directory tree or a mtree manifest .Sh SYNOPSIS .Nm -.Op Fl Dpx +.Op Fl DpXx .Op Fl B Ar byte-order .Op Fl b Ar free-blocks .Op Fl d Ar debug-mask @@ -155,7 +155,10 @@ isn't provided, the current time will be used. If .Sy flags isn't provided, the current file flags will be used. -Missing regular file entries will be created as zero-length files. +Missing regular file entries will be created as zero-length files +unless +.Fl X +is specified. .It Fl f Ar free-files Ensure that a minimum of .Ar free-files @@ -211,6 +214,12 @@ BSD fast file system (default). .It Sy cd9660 ISO 9660 file system. .El +.It Fl X +If a regular file listed in the specfile does not exist in the file system, +and the entry is not marked +.Sy optional , +abort creation of the image. Without this flag, the image would contain +a zero-length file in this case. .It Fl x Exclude file system nodes not explicitly listed in the specfile. .El diff --git a/usr.sbin/makefs/makefs.c b/usr.sbin/makefs/makefs.c index 03ff1ac..32f3469 100644 --- a/usr.sbin/makefs/makefs.c +++ b/usr.sbin/makefs/makefs.c @@ -113,7 +113,7 @@ main(int argc, char *argv[]) start_time.tv_sec = start.tv_sec; start_time.tv_nsec = start.tv_usec * 1000; - while ((ch = getopt(argc, argv, "B:b:Dd:f:F:M:m:N:o:ps:S:t:x")) != -1) { + while ((ch = getopt(argc, argv, "B:b:Dd:f:F:M:m:N:o:ps:S:t:Xx")) != -1) { switch (ch) { case 'B': @@ -229,6 +229,10 @@ main(int argc, char *argv[]) fstype->prepare_options(&fsoptions); break; + case 'X': + fsoptions.specrequired = 1; + break; + case 'x': fsoptions.onlyspec = 1; break; @@ -252,6 +256,10 @@ main(int argc, char *argv[]) if (argc < 2) usage(); + /* -X must be accompanied by -F */ + if (fsoptions.specrequired != 0 && specfile == NULL) + errx(1, "-X requires -F mtree-specfile."); + /* -x must be accompanied by -F */ if (fsoptions.onlyspec != 0 && specfile == NULL) errx(1, "-x requires -F mtree-specfile."); @@ -295,7 +303,8 @@ main(int argc, char *argv[]) if (specfile) { /* apply a specfile */ TIMER_START(start); - apply_specfile(specfile, subtree, root, fsoptions.onlyspec); + apply_specfile(specfile, subtree, root, fsoptions.onlyspec, + fsoptions.specrequired); TIMER_RESULTS(start, "apply_specfile"); } @@ -354,7 +363,7 @@ usage(void) fprintf(stderr, "usage: %s [-t fs-type] [-o fs-options] [-d debug-mask] [-B endian]\n" "\t[-S sector-size] [-M minimum-size] [-m maximum-size] [-s image-size]\n" -"\t[-b free-blocks] [-f free-files] [-F mtree-specfile] [-px]\n" +"\t[-b free-blocks] [-f free-files] [-F mtree-specfile [-X] [-x]] [-p]\n" "\t[-N userdb-dir] image-file directory | manifest [extra-directory ...]\n", prog); exit(1); diff --git a/usr.sbin/makefs/makefs.h b/usr.sbin/makefs/makefs.h index 5ab0444..ebb5e8c 100644 --- a/usr.sbin/makefs/makefs.h +++ b/usr.sbin/makefs/makefs.h @@ -118,6 +118,7 @@ typedef struct { int fd; /* file descriptor of image */ void *superblock; /* superblock */ int onlyspec; /* only add entries in specfile */ + int specrequired; /* entries in specfile are required to exist */ /* global options */ @@ -149,7 +150,7 @@ typedef struct { } option_t; -void apply_specfile(const char *, const char *, fsnode *, int); +void apply_specfile(const char *, const char *, fsnode *, int, int); void dump_fsnodes(fsnode *); const char * inode_type(mode_t); fsnode * read_mtree(const char *, fsnode *); diff --git a/usr.sbin/makefs/walk.c b/usr.sbin/makefs/walk.c index 2fc964a..d071692 100644 --- a/usr.sbin/makefs/walk.c +++ b/usr.sbin/makefs/walk.c @@ -55,7 +55,7 @@ __FBSDID("$FreeBSD$"); #include "mtree.h" #include "extern.h" -static void apply_specdir(const char *, NODE *, fsnode *, int); +static void apply_specdir(const char *, NODE *, fsnode *, int, int); static void apply_specentry(const char *, NODE *, fsnode *); static fsnode *create_fsnode(const char *, const char *, const char *, struct stat *); @@ -285,10 +285,11 @@ free_fsnodes(fsnode *node) * read in the mtree(8) specfile, and apply it to the tree * at dir,parent. parameters in parent on equivalent types * will be changed to those found in specfile, and missing - * entries will be added. + * entries will be added if specrequired is false. */ void -apply_specfile(const char *specfile, const char *dir, fsnode *parent, int speconly) +apply_specfile(const char *specfile, const char *dir, fsnode *parent, + int speconly, int specrequired) { struct timeval start; FILE *fp; @@ -316,12 +317,13 @@ apply_specfile(const char *specfile, const char *dir, fsnode *parent, int specon assert(root->type == F_DIR); /* merge in the changes */ - apply_specdir(dir, root, parent, speconly); + apply_specdir(dir, root, parent, speconly, specrequired); } static void -apply_specdir(const char *dir, NODE *specnode, fsnode *dirnode, int speconly) +apply_specdir(const char *dir, NODE *specnode, fsnode *dirnode, int speconly, + int specrequired) { char path[MAXPATHLEN + 1]; NODE *curnode; @@ -388,13 +390,22 @@ apply_specdir(const char *dir, NODE *specnode, fsnode *dirnode, int speconly) if (curfsnode == NULL) { /* need new entry */ struct stat stbuf; - /* - * don't add optional spec entries - * that lack an existing fs entry - */ - if ((curnode->flags & F_OPT) && - lstat(path, &stbuf) == -1) + if (lstat(path, &stbuf) == -1) { + /* + * don't add optional spec entries + * that lack an existing fs entry + */ + if (curnode->flags & F_OPT) continue; + /* + * When specrequired is true, abort + * if a non-optional regular file + * lacks an existing fs entry. + */ + if (specrequired && curnode->type == F_FILE) + err(1, "`%s', required by specfile", + path); + } /* check that enough info is provided */ #define NODETEST(t, m) \ @@ -451,7 +462,8 @@ apply_specdir(const char *dir, NODE *specnode, fsnode *dirnode, int speconly) if (curfsnode->type != S_IFDIR) errx(1, "`%s' is not a directory", path); assert (curfsnode->child != NULL); - apply_specdir(path, curnode, curfsnode->child, speconly); + apply_specdir(path, curnode, curfsnode->child, speconly, + specrequired); } } } --------------040609050209020303070807-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 15 21:40:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 82F16BCE; Thu, 15 Aug 2013 21:40:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C3882BA0; Thu, 15 Aug 2013 21:40:48 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id h14so634130eak.29 for ; Thu, 15 Aug 2013 14:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=LjxekYHvC+iIKiI94sZqU16MN2ruOFa5AWPUBnQ+vtM=; b=js3WYVdRQFzSNF1xwd4hhesO53tCk9qjFYpYjKhwb1goSQcXysQkN3N9J4smm1lKrQ HkO4bXrlDb9QHLPBFhBU3ZJ5yoyOdrFipGVbG19IsNvy5hLZQxEbBwEJ1YmacLHNlJ87 2kDneupclCz583g3VVxSiuzg9q+UgNQSUBwJPeRPnBgJlSMjBYGFyVbnwlpNw+WzTqGe a0uAwObk3zBDRI5IWNV7yBTZD3tnY+B6BUj+u4WrVk9ZfjPJyMRmr+lSQhB8rP68Th9j z1U8iFDFEmRJCtaZpiFXvkFXQRPcAAuQqB3M96gvGsDG+dsY1r4dtQ/NVxe3WvZbQIpP xb+w== X-Received: by 10.15.90.132 with SMTP id q4mr180193eez.98.1376602846545; Thu, 15 Aug 2013 14:40:46 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([37.229.21.195]) by mx.google.com with ESMTPSA id k7sm1995775eeg.13.2013.08.15.14.40.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 14:40:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <520D4ADB.50209@FreeBSD.org> Date: Fri, 16 Aug 2013 00:40:43 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD SCSI , freebsd-hackers@FreeBSD.org, "Justin T. Gibbs" , Scott Long , ken , Jeff Roberson , Steven Hartland Subject: New CAM locking preview Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 21:40:49 -0000 Hi. Last weeks I've made substantial progress on my CAM locking work. In fact, at this moment I think I've tied all loose ends good enough to consider the new design viable and implementation worth further testing and bug fixing. So I would like to ask for review of my work from everybody who interested in CAM internals. In short, my idea was to split single per-SIM lock, that creates huge congestion under high IOPS, into several smaller ones. So design I've finally chosen includes such locks: 1) New per-device (per-LUN) locks to protect state of the devices and respective periphs. In most cases peripheral drivers just use that lock instead of SIM lock used before, so code modification is minimal and straightforward. 2) New per-target lock to protect list of LUNs fetched from the device. 3) Old single per-SIM lock to protect SIM driver internals, but only that. No parts of CAM itself use that lock. Keeping it for SIMs allows to keep API and hopefully ABI compatibility. Reducing its scope allows to reduce congestion. 4) New per-SIM lock to protect SIM and device command queues. That allows execute queued commands from any context unrelated to other locks. Also this lock serializes accesses to sim_action() method for the most of commands, this allows to mostly avoid busy spilling on SIM lock collision. 5) New per-bus locks to protect target, device and periphs reference counters. It allows to create and destroy paths unrelated to other locks in any possible context. Numbers above also define supposed lock ordering: while holding per-device lock 1) is allowed to request SIM lock 3), but not backward. Cases where opposite is required (command completions and async events) are handled via queuing events via several completion threads. The rest of locks are self-contained and does not really suppose cascading. All these changes combined with GEOM direct dispatch (it will be next separate project) allow to double system performance in disk I/O microbenchmarks, comparing to present head, same as it was announced on 2013-05 DevSummit: http://people.freebsd.org/~mav/camlock.pdf . Tests without GEOM changes also show performance improvement, but limited by heavy bottleneck at the GEOM g_up/g_down threads at the level of 5-20%. Project sources could be found at SVN projects/camlock branch: http://svnweb.freebsd.org/base/projects/camlock/ . Many early changes from that branch are already integrated to head, so to simplify review the rest patches for changes before r254059 were manually remade and could be found here: http://people.freebsd.org/~mav/camlock_patches/ . These changes do not require controller driver modifications, keeping KPIs and hopefully KBIs intact, but create base for later work to use multiqueue capabilities of new controllers. This work is sponsored by iXsystems, Inc. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 15 22:38:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E51A3585 for ; Thu, 15 Aug 2013 22:38:44 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C07EE2DEA for ; Thu, 15 Aug 2013 22:38:44 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VA6Bg-0005Jk-R8 for freebsd-hackers@freebsd.org; Thu, 15 Aug 2013 15:38:36 -0700 Date: Thu, 15 Aug 2013 15:38:36 -0700 (PDT) From: Jakub Lach To: freebsd-hackers@freebsd.org Message-ID: <1376606316815-5836490.post@n5.nabble.com> In-Reply-To: <4F5FAF1B.1080102@freebsd.org> References: <4F5FAF1B.1080102@freebsd.org> Subject: Re: will 9.2 be called 'diehard'? or maybe Naktomi? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 22:38:45 -0000 Well, that took me by surprise... -- View this message in context: http://freebsd.1045724.n5.nabble.com/will-9-2-be-called-diehard-or-maybe-Naktomi-tp5562525p5836490.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 15 23:40:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 46DE8D5A for ; Thu, 15 Aug 2013 23:40:23 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24F2D2072 for ; Thu, 15 Aug 2013 23:40:23 +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 98062E6001 for ; Thu, 15 Aug 2013 16:40:16 -0700 (PDT) Received: from [192.168.1.102] (static-71-242-248-73.phlapa.east.verizon.net [71.242.248.73]) by chombo.houseloki.net (Postfix) with ESMTPSA id 83B2938C for ; Thu, 15 Aug 2013 16:40:14 -0700 (PDT) Message-ID: <520D66D6.7040805@bluerosetech.com> Date: Thu, 15 Aug 2013 19:40:06 -0400 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: will 9.2 be called 'diehard'? or maybe Naktomi? References: <4F5FAF1B.1080102@freebsd.org> <1376606316815-5836490.post@n5.nabble.com> In-Reply-To: <1376606316815-5836490.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:40:23 -0000 > http://freebsd.1045724.n5.nabble.com/will-9-2-be-called-diehard-or-maybe-Naktomi-tp5562525p5836490.html Perhaps a creative type might do up McKusick's mascot a la Bruce Willis. Bonus points for weapon hosters made from Christmas gift wrap tape. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 15 23:41:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BAD0AE58 for ; Thu, 15 Aug 2013 23:41:57 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9198A20A8 for ; Thu, 15 Aug 2013 23:41:57 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj1so1243797pad.0 for ; Thu, 15 Aug 2013 16:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OmIote9x+GGhw2OJFL4QWtTiQ8xXWHbq1oiLtmfvc88=; b=mqCuCtnM0wBnX7uGjY/NvgaprdFIiC2R8sLIrjKBXkFEZVIGd95TPGLeNiQ/DUnBBd PMlk1Rd4XuqalOgORQlACnOprCplHUWfQDvScz4h+GJdqrKDHsFPO+XjXE6DTGYbcHwg N+TkESRqBhrefHtIibY1ODxMagFxu8Twp66Bc6tC7dGe7PeIqsFcTvKHP9PPqGqIm+u7 u+S1xNdrKV7x5YXZLvaCq3zm1BW+oaMeQF8pXN0fU1ZYhdO5W/W2jWLhcd08aUXHGcU4 OTXHr4Uywzc3SMxAEgZb9ckKhZrfIzEg+oYqjCXFyylpqQeQigCIx+B+jfDlL047ZS33 u9Ow== X-Received: by 10.66.246.225 with SMTP id xz1mr45207pac.110.1376610117198; Thu, 15 Aug 2013 16:41:57 -0700 (PDT) Received: from kruse-64.3.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPSA id ys4sm2437294pbb.9.2013.08.15.16.41.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 16:41:56 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: will 9.2 be called 'diehard'? or maybe Naktomi? From: "Jordan K. Hubbard" In-Reply-To: <1376606316815-5836490.post@n5.nabble.com> Date: Thu, 15 Aug 2013 16:41:54 -0700 Message-Id: <21B93DC0-1CBC-4C23-B633-0997C5AE0A34@turbofuzz.com> References: <4F5FAF1B.1080102@freebsd.org> <1376606316815-5836490.post@n5.nabble.com> To: Jakub Lach X-Mailer: Apple Mail (2.1510) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:41:57 -0000 On Aug 15, 2013, at 3:38 PM, Jakub Lach wrote: > Well, that took me by surprise... That's probably the same thing 20th Century Fox's legal counsel said = this morning. ;-) From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 00:37:07 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 17A909B8; Fri, 16 Aug 2013 00:37:07 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 98AE022F0; Fri, 16 Aug 2013 00:37:06 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 0F59D7A28D; Fri, 16 Aug 2013 02:36:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 978818EE897; Fri, 16 Aug 2013 02:37:08 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCgvGLR2GiZr; Fri, 16 Aug 2013 02:37:07 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 750858EE895; Fri, 16 Aug 2013 02:37:07 +0200 (CEST) Message-ID: <520D7479.3060505@bitfrost.no> Date: Fri, 16 Aug 2013 02:38:17 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alexander Motin Subject: Re: New CAM locking preview References: <520D4ADB.50209@FreeBSD.org> In-Reply-To: <520D4ADB.50209@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Long , Jeff Roberson , ken , freebsd-hackers@FreeBSD.org, FreeBSD SCSI , Steven Hartland , "Justin T. Gibbs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 00:37:07 -0000 On 08/15/13 23:40, Alexander Motin wrote: > Hi. > > Last weeks I've made substantial progress on my CAM locking work. In > fact, at this moment I think I've tied all loose ends good enough to > consider the new design viable and implementation worth further testing > and bug fixing. So I would like to ask for review of my work from > everybody who interested in CAM internals. > > In short, my idea was to split single per-SIM lock, that creates huge > congestion under high IOPS, into several smaller ones. So design I've > finally chosen includes such locks: > 1) New per-device (per-LUN) locks to protect state of the devices and > respective periphs. In most cases peripheral drivers just use that lock > instead of SIM lock used before, so code modification is minimal and > straightforward. > 2) New per-target lock to protect list of LUNs fetched from the device. > 3) Old single per-SIM lock to protect SIM driver internals, but only > that. No parts of CAM itself use that lock. Keeping it for SIMs allows > to keep API and hopefully ABI compatibility. Reducing its scope allows > to reduce congestion. > 4) New per-SIM lock to protect SIM and device command queues. That > allows execute queued commands from any context unrelated to other > locks. Also this lock serializes accesses to sim_action() method for the > most of commands, this allows to mostly avoid busy spilling on SIM lock > collision. > 5) New per-bus locks to protect target, device and periphs reference > counters. It allows to create and destroy paths unrelated to other locks > in any possible context. > Sounds very good! I assume you have tested USB mass storage device unplug during various file system operations? --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 00:45:44 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5408DB84; Fri, 16 Aug 2013 00:45:44 +0000 (UTC) (envelope-from prvs=1940958969=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04DCB2350; Fri, 16 Aug 2013 00:45:42 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005518017.msg; Fri, 16 Aug 2013 01:45:40 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 16 Aug 2013 01:45:40 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1940958969=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <86A1FDF5CDCD42DD8CE438576DBB1839@multiplay.co.uk> From: "Steven Hartland" To: "Hans Petter Selasky" , "Alexander Motin" References: <520D4ADB.50209@FreeBSD.org> <520D7479.3060505@bitfrost.no> Subject: Re: New CAM locking preview Date: Fri, 16 Aug 2013 01:45:58 +0100 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: Scott Long , Jeff Roberson , ken , freebsd-hackers@FreeBSD.org, FreeBSD SCSI , "Justin T. Gibbs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 00:45:44 -0000 ----- Original Message ----- From: "Hans Petter Selasky" To: "Alexander Motin" Cc: "Scott Long" ; "Jeff Roberson" ; "ken" ; ; "FreeBSD SCSI" ; "Steven Hartland" ; "Justin T. Gibbs" Sent: Friday, August 16, 2013 1:38 AM Subject: Re: New CAM locking preview > On 08/15/13 23:40, Alexander Motin wrote: >> Hi. >> >> Last weeks I've made substantial progress on my CAM locking work. In >> fact, at this moment I think I've tied all loose ends good enough to >> consider the new design viable and implementation worth further testing >> and bug fixing. So I would like to ask for review of my work from >> everybody who interested in CAM internals. >> >> In short, my idea was to split single per-SIM lock, that creates huge >> congestion under high IOPS, into several smaller ones. So design I've >> finally chosen includes such locks: >> 1) New per-device (per-LUN) locks to protect state of the devices and >> respective periphs. In most cases peripheral drivers just use that lock >> instead of SIM lock used before, so code modification is minimal and >> straightforward. >> 2) New per-target lock to protect list of LUNs fetched from the device. >> 3) Old single per-SIM lock to protect SIM driver internals, but only >> that. No parts of CAM itself use that lock. Keeping it for SIMs allows >> to keep API and hopefully ABI compatibility. Reducing its scope allows >> to reduce congestion. >> 4) New per-SIM lock to protect SIM and device command queues. That >> allows execute queued commands from any context unrelated to other >> locks. Also this lock serializes accesses to sim_action() method for the >> most of commands, this allows to mostly avoid busy spilling on SIM lock >> collision. >> 5) New per-bus locks to protect target, device and periphs reference >> counters. It allows to create and destroy paths unrelated to other locks >> in any possible context. >> > > Sounds very good! I assume you have tested USB mass storage device unplug during various file system operations? It does indeed sound like some very good work, thanks Alexander! @Hans if USB mass storage device unplug is something important to you then might I suggest its a good idea to grab the patches, run your own tests and report any issues you might find as I'm sure this would be most appreciated :) 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-hackers@FreeBSD.ORG Fri Aug 16 01:12:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39F69F86; Fri, 16 Aug 2013 01:12:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF1E02472; Fri, 16 Aug 2013 01:12:07 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k13so1073334wgh.13 for ; Thu, 15 Aug 2013 18:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PHq+4h2tXFQIradobpqSO0JKQm6cWJqoq9eumez+nrI=; b=Pt/Gkz6gbsbEVj37cdNsoGvKIs60uRHqhlS4IciYXcT8OavkzuWUs2yHGjz5xvOXut ZmIp13BkFSx29IVlKd/PqW92zmiuQm2gc+V+LnfNvTYBuYOzsj1Tkbadb5171WYlx4IX kO5Y7cMFuLTp9rpfsjZcABwngj+qJ2kOdMEIGjT+bKgW+qH1k0AOKM2adLua+p7x8bTP IGZV8WNfca+rYwG7b2SqC4zWTgi4GokBQhvusgiyQWhT+G5Li/4To7ezDgyIfqDXGTGN gAp8GwNcBebY4VUxHY6ai7TlaGrLNSog1g2NqgsPYfaKtY937mauZjsyW0ZXDf7QRoiM D/UA== MIME-Version: 1.0 X-Received: by 10.180.37.16 with SMTP id u16mr226772wij.46.1376615525882; Thu, 15 Aug 2013 18:12:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Thu, 15 Aug 2013 18:12:05 -0700 (PDT) In-Reply-To: <520D4ADB.50209@FreeBSD.org> References: <520D4ADB.50209@FreeBSD.org> Date: Thu, 15 Aug 2013 18:12:05 -0700 X-Google-Sender-Auth: D6pqo5evTjWdHMuJBBeiW4ha7JA Message-ID: Subject: Re: New CAM locking preview From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Scott Long , Jeff Roberson , ken , "freebsd-hackers@freebsd.org" , FreeBSD SCSI , Steven Hartland , "Justin T. Gibbs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 01:12:09 -0000 Cool! I assume you've run this with full witness debugging enabled, to catch lock ordering issues? This is great. I look forward to per-CPU, pinned, completion threads that I can do interesting things with (like schedule aio-sendfile completions..) -adrian On 15 August 2013 14:40, Alexander Motin wrote: > Hi. > > Last weeks I've made substantial progress on my CAM locking work. In fact, > at this moment I think I've tied all loose ends good enough to consider the > new design viable and implementation worth further testing and bug fixing. > So I would like to ask for review of my work from everybody who interested > in CAM internals. > > In short, my idea was to split single per-SIM lock, that creates huge > congestion under high IOPS, into several smaller ones. So design I've > finally chosen includes such locks: > 1) New per-device (per-LUN) locks to protect state of the devices and > respective periphs. In most cases peripheral drivers just use that lock > instead of SIM lock used before, so code modification is minimal and > straightforward. > 2) New per-target lock to protect list of LUNs fetched from the device. > 3) Old single per-SIM lock to protect SIM driver internals, but only > that. No parts of CAM itself use that lock. Keeping it for SIMs allows to > keep API and hopefully ABI compatibility. Reducing its scope allows to > reduce congestion. > 4) New per-SIM lock to protect SIM and device command queues. That allows > execute queued commands from any context unrelated to other locks. Also > this lock serializes accesses to sim_action() method for the most of > commands, this allows to mostly avoid busy spilling on SIM lock collision. > 5) New per-bus locks to protect target, device and periphs reference > counters. It allows to create and destroy paths unrelated to other locks in > any possible context. > > Numbers above also define supposed lock ordering: while holding per-device > lock 1) is allowed to request SIM lock 3), but not backward. Cases where > opposite is required (command completions and async events) are handled via > queuing events via several completion threads. The rest of locks are > self-contained and does not really suppose cascading. > > All these changes combined with GEOM direct dispatch (it will be next > separate project) allow to double system performance in disk I/O > microbenchmarks, comparing to present head, same as it was announced on > 2013-05 DevSummit: http://people.freebsd.org/~**mav/camlock.pdf. Tests without GEOM changes also show performance improvement, but limited > by heavy bottleneck at the GEOM g_up/g_down threads at the level of 5-20%. > > Project sources could be found at SVN projects/camlock branch: > http://svnweb.freebsd.org/**base/projects/camlock/. Many early changes from that branch are already integrated to head, so to > simplify review the rest patches for changes before r254059 were manually > remade and could be found here: http://people.freebsd.org/~** > mav/camlock_patches/ . > > These changes do not require controller driver modifications, keeping KPIs > and hopefully KBIs intact, but create base for later work to use multiqueue > capabilities of new controllers. > > This work is sponsored by iXsystems, Inc. > > -- > Alexander Motin > ______________________________**_________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** > freebsd.org " > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 01:16:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A098F1D8 for ; Fri, 16 Aug 2013 01:16:34 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64D4524A3 for ; Fri, 16 Aug 2013 01:16:34 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id tp5so2492866ieb.41 for ; Thu, 15 Aug 2013 18:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MmwaXQN6Hh76/TdxuZKvYFrWsOp7tv7G4dT2hxwLsew=; b=fpyWghXcjfvsvuOZ/xHB9mbW1mHUIwABEBCzH280tTAWEv5HiBuP92U5ddUl0knzsU fZLAObgziKVLl627JTfPC7rEJuBlGYkyrwyNg6lcjZ1PIWB/KRrEqcjmiqE1V+ydePva LBbfzOd0BMBgD1N7xIhM82tJR4hjqXYN//Jhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MmwaXQN6Hh76/TdxuZKvYFrWsOp7tv7G4dT2hxwLsew=; b=PPr3yE+ch++MX8AnZKId4jlTx6mmvRNHriEZ00sI9QXnyg6e8QuSXdTWmz+ZDIxpFQ iSEw//RQnJP74LalcsNt1n69osygPDj3k9dCFBS83F243/yIC3MX9NQXmyW8+3q/1few ManF9wSAInoqyq+TODug7egEqvGaBbQkUYLI7FUobGs+TgyiN7LwSC/kqEFnJRG4BidJ CW4r3wIZuEauSD6/ir2TN4VU85zhO+Ej7mLdu40Uqj0W3co1iK4uk7TIUJqRkvX88GiK CTEBXHbk4zwPoWLsvC4Dsi/lNr4ggZYkntyhomTRj2yglc8qZdZXkQCY6BN3scdggdZW 0zmw== X-Gm-Message-State: ALoCoQlSI94P80lApIOrkcXb7ujjrw23F9Pj58BqHRsEBqKm4DJgNtJQ3/zazAnOp37L9VJjPUKc X-Received: by 10.42.41.210 with SMTP id q18mr9559373ice.13.1376615793312; Thu, 15 Aug 2013 18:16:33 -0700 (PDT) Received: from [192.168.31.77] (75-128-120-29.dhcp.aldl.mi.charter.com. [75.128.120.29]) by mx.google.com with ESMTPSA id p10sm7665779igx.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 18:16:31 -0700 (PDT) References: <4F5FAF1B.1080102@freebsd.org> <1376606316815-5836490.post@n5.nabble.com> <520D66D6.7040805@bluerosetech.com> Mime-Version: 1.0 (1.0) In-Reply-To: <520D66D6.7040805@bluerosetech.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-610A5B9A-484F-43CA-946C-54C33519C088; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <0B27F399-375D-46ED-B504-6B6E880F78BF@dataix.net> X-Mailer: iPhone Mail (10B350) From: Jason Hellenthal Subject: Re: will 9.2 be called 'diehard'? or maybe Naktomi? Date: Thu, 15 Aug 2013 21:16:29 -0400 To: Darren Pilgrim X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 01:16:34 -0000 --Apple-Mail-610A5B9A-484F-43CA-946C-54C33519C088 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Has a release ever been nicknamed before ?=20 I don't recall any. --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Aug 15, 2013, at 19:40, Darren Pilgrim wr= ote: >> http://freebsd.1045724.n5.nabble.com/will-9-2-be-called-diehard-or-maybe-= Naktomi-tp5562525p5836490.html >=20 > Perhaps a creative type might do up McKusick's mascot a la Bruce Willis. B= onus points for weapon hosters made from Christmas gift wrap tape. >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= --Apple-Mail-610A5B9A-484F-43CA-946C-54C33519C088 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgxNjAxMTYzMFowIwYJKoZIhvcN AQkEMRYEFJxV3jCGCG9j2m5jZuZ98gB0AXRzMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEALH9gP7AkFZEqmTs4GZcX IpfJbmW0TkvkwyDK12LRtCMkMcKQq44wmWPtH7dko8F2rjbfj1svkQSVXtIqfa7zU0BarA/g8auS UGXTNDXLAMmj2LVbMKNORDX9ICF3+eYxET7EQf7aOz/APyqLdbIU4rd5d/NLKdJBj8lcY191+113 G1rOI0+SKpaUofKP/6Jn6J+AVvlEJmnMpUfLuggwTuFSTiQJucgaQbOa53qB0UU1JgHp/awdc3K1 CQqinZ+W5m7BHSP458anMjt4Ltk8BQZgHD5cEdUfQ1q7pE2bJIBkxRYM/0SNDhhj+zAGK1D4qQOi PuYy20rz3lgyukTrAgAAAAAAAA== --Apple-Mail-610A5B9A-484F-43CA-946C-54C33519C088-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 01:18:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0BADE2D8 for ; Fri, 16 Aug 2013 01:18:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99D4E24B9 for ; Fri, 16 Aug 2013 01:18:56 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id q55so1164194wes.30 for ; Thu, 15 Aug 2013 18:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PAYyS/5ILupJ8/iK+I21CufBKOVvCejF1g+z8sGVfTg=; b=AmYe6z3Jno1h1a8FrQnMkWjrDcXEBPlxtwVGs5ZIOYmMPwJSR6mm7L3cX9IU+yhgmj ngXpi8DS0ua4ZRLuS8eO6/wwWkF6e1KDG5WwMFNmpj/r+AZY918UzY9yEJXxnLp0wsCD NZb/5FpzniHVNzl4f5yukwptSMWhNumv5i8Xu3QyDI+qtcgya69PM0QpioMk9Myp/t4V 8BjT2xZVo0B0BGF1xe2Q8M5gZp8pd6krnQPuUwXpG56nNLJcvlqV5JGkSCJWPNN8InRA Sl2U6lvUZW2dkegZ15IukgTZUK1zTvtZ9BkYeIxvtuqOZi+9BFNcR01AXnteaFvSiaJb m+iw== MIME-Version: 1.0 X-Received: by 10.180.8.42 with SMTP id o10mr3649339wia.0.1376615934771; Thu, 15 Aug 2013 18:18:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Thu, 15 Aug 2013 18:18:54 -0700 (PDT) In-Reply-To: <0B27F399-375D-46ED-B504-6B6E880F78BF@dataix.net> References: <4F5FAF1B.1080102@freebsd.org> <1376606316815-5836490.post@n5.nabble.com> <520D66D6.7040805@bluerosetech.com> <0B27F399-375D-46ED-B504-6B6E880F78BF@dataix.net> Date: Thu, 15 Aug 2013 18:18:54 -0700 X-Google-Sender-Auth: 6p_049oxRBlN1-BfQ5JcnHlR_nc Message-ID: Subject: Re: will 9.2 be called 'diehard'? or maybe Naktomi? From: Adrian Chadd To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" , Darren Pilgrim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 01:18:57 -0000 Oh look at that. It's so damned pretty. -adrian On 15 August 2013 18:16, Jason Hellenthal wrote: > Has a release ever been nicknamed before ? > > I don't recall any. > > -- > Jason Hellenthal > Inbox: jhellenthal@DataIX.net > Voice: +1 (616) 953-0176 > JJH48-ARIN > > > On Aug 15, 2013, at 19:40, Darren Pilgrim > wrote: > > >> > http://freebsd.1045724.n5.nabble.com/will-9-2-be-called-diehard-or-maybe-Naktomi-tp5562525p5836490.html > > > > Perhaps a creative type might do up McKusick's mascot a la Bruce Willis. > Bonus points for weapon hosters made from Christmas gift wrap tape. > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 06:51:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2930AD5; Fri, 16 Aug 2013 06:51:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8910F23BE; Fri, 16 Aug 2013 06:51:25 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id d51so768042eek.37 for ; Thu, 15 Aug 2013 23:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KnwRBAjKnIuR3HOQY/riLwATfVN+0cHyD8Je4BbaQb0=; b=tEL4dRivnVqSd9ABdiJRI1703tNB6meeYFHwaCdRD29PhK9s1paMWLyOj212wIHCXf 150+zMDUtfu8kshqajvT8CDAVXTvNsWbKKeoBgA+3X9N2jFoMj2IILyFpDAvk/Bxp9g5 NzpXVJgQUFTRtsMNDxb0qtW/6Rk8g0VdPgyggszmDYIUaLwRdR/aQbWWqrx7AP4D6njM cE5RG9EYIl+0i+T4rEIlWycQLd/BgJlrL2l7dcZ5fb0jPLE6vjaw7VMy5gK5WDyseoiw /X4AJGraTCpRujGgcdO/fAJzxMRbr0S0G87iqoGnRDARCvEvkYjA3QzmLnvtyYdMooxr 9GLQ== X-Received: by 10.15.76.71 with SMTP id m47mr26109eey.85.1376635883909; Thu, 15 Aug 2013 23:51:23 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([37.229.21.195]) by mx.google.com with ESMTPSA id bq1sm210635eeb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 23:51:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <520DCBE8.9050703@FreeBSD.org> Date: Fri, 16 Aug 2013 09:51:20 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: New CAM locking preview References: <520D4ADB.50209@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Long , Jeff Roberson , ken , "freebsd-hackers@freebsd.org" , FreeBSD SCSI , Steven Hartland , "Justin T. Gibbs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 06:51:27 -0000 On 16.08.2013 04:12, Adrian Chadd wrote: > Cool! > > I assume you've run this with full witness debugging enabled, to catch > lock ordering issues? Of course! I've endless times switched between debug and normal builds to test both correctness and performance after each change. But more external tests are welcome. > This is great. I look forward to per-CPU, pinned, completion threads > that I can do interesting things with (like schedule aio-sendfile > completions..) > > On 15 August 2013 14:40, Alexander Motin > wrote: > > Hi. > > Last weeks I've made substantial progress on my CAM locking work. In > fact, at this moment I think I've tied all loose ends good enough to > consider the new design viable and implementation worth further > testing and bug fixing. So I would like to ask for review of my work > from everybody who interested in CAM internals. > > In short, my idea was to split single per-SIM lock, that creates > huge congestion under high IOPS, into several smaller ones. So > design I've finally chosen includes such locks: > 1) New per-device (per-LUN) locks to protect state of the devices > and respective periphs. In most cases peripheral drivers just use > that lock instead of SIM lock used before, so code modification is > minimal and straightforward. > 2) New per-target lock to protect list of LUNs fetched from the > device. > 3) Old single per-SIM lock to protect SIM driver internals, but > only that. No parts of CAM itself use that lock. Keeping it for SIMs > allows to keep API and hopefully ABI compatibility. Reducing its > scope allows to reduce congestion. > 4) New per-SIM lock to protect SIM and device command queues. That > allows execute queued commands from any context unrelated to other > locks. Also this lock serializes accesses to sim_action() method for > the most of commands, this allows to mostly avoid busy spilling on > SIM lock collision. > 5) New per-bus locks to protect target, device and periphs > reference counters. It allows to create and destroy paths unrelated > to other locks in any possible context. > > Numbers above also define supposed lock ordering: while holding > per-device lock 1) is allowed to request SIM lock 3), but not > backward. Cases where opposite is required (command completions and > async events) are handled via queuing events via several completion > threads. The rest of locks are self-contained and does not really > suppose cascading. > > All these changes combined with GEOM direct dispatch (it will be > next separate project) allow to double system performance in disk > I/O microbenchmarks, comparing to present head, same as it was > announced on 2013-05 DevSummit: > http://people.freebsd.org/~__mav/camlock.pdf > . Tests without GEOM > changes also show performance improvement, but limited by heavy > bottleneck at the GEOM g_up/g_down threads at the level of 5-20%. > > Project sources could be found at SVN projects/camlock branch: > http://svnweb.freebsd.org/__base/projects/camlock/ > . Many early > changes from that branch are already integrated to head, so to > simplify review the rest patches for changes before r254059 were > manually remade and could be found here: > http://people.freebsd.org/~__mav/camlock_patches/ > . > > These changes do not require controller driver modifications, > keeping KPIs and hopefully KBIs intact, but create base for later > work to use multiqueue capabilities of new controllers. > > This work is sponsored by iXsystems, Inc. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 08:16:11 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22AC7F0F; Fri, 16 Aug 2013 08:16:11 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7B752743; Fri, 16 Aug 2013 08:16:10 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 504B7B70D2; Fri, 16 Aug 2013 08:16:03 +0000 (UTC) Date: Fri, 16 Aug 2013 10:16:03 +0200 From: Jeremie Le Hen To: Alexander Motin Subject: Re: New CAM locking preview Message-ID: <20130816081603.GA4984@caravan.chchile.org> Mail-Followup-To: Alexander Motin , FreeBSD SCSI , freebsd-hackers@FreeBSD.org, "Justin T. Gibbs" , Scott Long , ken , Jeff Roberson , Steven Hartland References: <520D4ADB.50209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520D4ADB.50209@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Scott Long , Jeff Roberson , ken , freebsd-hackers@FreeBSD.org, FreeBSD SCSI , Steven Hartland , "Justin T. Gibbs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 08:16:11 -0000 On Fri, Aug 16, 2013 at 12:40:43AM +0300, Alexander Motin wrote: > Hi. > > Last weeks I've made substantial progress on my CAM locking work. In > fact, at this moment I think I've tied all loose ends good enough to > consider the new design viable and implementation worth further testing > and bug fixing. So I would like to ask for review of my work from > everybody who interested in CAM internals. > > In short, my idea was to split single per-SIM lock, that creates huge > congestion under high IOPS, into several smaller ones. So design I've > finally chosen includes such locks: > 1) New per-device (per-LUN) locks to protect state of the devices and > respective periphs. In most cases peripheral drivers just use that lock > instead of SIM lock used before, so code modification is minimal and > straightforward. > 2) New per-target lock to protect list of LUNs fetched from the device. > 3) Old single per-SIM lock to protect SIM driver internals, but only > that. No parts of CAM itself use that lock. Keeping it for SIMs allows > to keep API and hopefully ABI compatibility. Reducing its scope allows > to reduce congestion. > 4) New per-SIM lock to protect SIM and device command queues. That > allows execute queued commands from any context unrelated to other > locks. Also this lock serializes accesses to sim_action() method for the > most of commands, this allows to mostly avoid busy spilling on SIM lock > collision. > 5) New per-bus locks to protect target, device and periphs reference > counters. It allows to create and destroy paths unrelated to other locks > in any possible context. > > Numbers above also define supposed lock ordering: while holding > per-device lock 1) is allowed to request SIM lock 3), but not backward. > Cases where opposite is required (command completions and async events) > are handled via queuing events via several completion threads. The rest > of locks are self-contained and does not really suppose cascading. > > All these changes combined with GEOM direct dispatch (it will be next > separate project) allow to double system performance in disk I/O > microbenchmarks, comparing to present head, same as it was announced on > 2013-05 DevSummit: http://people.freebsd.org/~mav/camlock.pdf . Tests > without GEOM changes also show performance improvement, but limited by > heavy bottleneck at the GEOM g_up/g_down threads at the level of 5-20%. > > Project sources could be found at SVN projects/camlock branch: > http://svnweb.freebsd.org/base/projects/camlock/ . Many early changes > from that branch are already integrated to head, so to simplify review > the rest patches for changes before r254059 were manually remade and > could be found here: http://people.freebsd.org/~mav/camlock_patches/ . > > These changes do not require controller driver modifications, keeping > KPIs and hopefully KBIs intact, but create base for later work to use > multiqueue capabilities of new controllers. > > This work is sponsored by iXsystems, Inc. Excellent, thanks to both you and iXsystems. I'm eager to see everything merged to -CURRENT before the code slush ;). -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 16 22:10:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 805F5158 for ; Fri, 16 Aug 2013 22:10:14 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44AE623DF for ; Fri, 16 Aug 2013 22:10:14 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ia10so1807952vcb.6 for ; Fri, 16 Aug 2013 15:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zP0N8fpsUQbUNggk/ylZVsR2seCxTwwOc7Jfr64DScg=; b=DNv7WTwZwy2nd8ZBY1Qym1r26ZMTBrcEeYe2QxW8O0ZcE4QmTWve0nsTrWWmUVCYHb qZBaw6n5ScUe/Hw/ahbX39z4D6lhl9wrrTSFYzhoo1q81f2l5rTx+UWkl+SJsVEFgJtQ 6vWsU3LBBKOi0V1dEUB1D83W0BUO+feObtCyCDj8rdoPKFyx3jQoXPNonjMiIrPdoiSk GayHWIrEdyY4ftpPNsq2nASoYWrqAxiCWmz8vQnoAXrvc8Apzjb2yYBu07WfJ7SEIMGi LhnOo/C6VhzkGQy99IkuP3jOAYG2mn3rR2ITxPohkJho9ZYZzofEakxj/CcSatjia5lH wU/A== MIME-Version: 1.0 X-Received: by 10.52.233.33 with SMTP id tt1mr2654039vdc.2.1376691013449; Fri, 16 Aug 2013 15:10:13 -0700 (PDT) Received: by 10.58.232.41 with HTTP; Fri, 16 Aug 2013 15:10:13 -0700 (PDT) Date: Fri, 16 Aug 2013 15:10:13 -0700 Message-ID: Subject: User Space DTrace and dumping function arguments for user space From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 22:10:14 -0000 Can we dump function arguments for user space functions just like for functions in kernel space? Can FBT provider dump arguments for user space functions if we do dtrace -l -f -v? I was DTrace'ing "top" utility, (the "top" utility has both the CTF and the Dwarf debug sections built in the object file) I am trying to inspect get_system_info function called by "top", I confirm it is present to be probed root% dtrace -l | grep get_system_info 55154 pid8488 top get_system_info entry But I cannot dump the arguments to the function... root% dtrace -l -f get_system_info -v ID PROVIDER MODULE FUNCTION NAME 55154 pid8488 top get_system_info entry Probe Description Attributes Identifier Names: Private Data Semantics: Private Dependency Class: Unknown Argument Attributes Identifier Names: Private Data Semantics: Private Dependency Class: Unknown Argument Types None Testing with a simple script, pid8488::get_system_info:entry { this->info = (struct system_info *)copyin(args[0], sizeof(struct system_info)); ... } ...if I use the args[0] notation it says the following, dtrace: failed to compile script top_d.d: line 17: index 0 is out of range for pid8488::get_system_info:entry args[ ] Instead if I replace with arg0, it compiles but the values are not neccesarily sane. Example the ncpus member of struct system_info shows a garbage value. The complete script is pid8488::get_system_info:entry { this->info = (struct system_info *)copyin(arg0, sizeof(struct system_info)); printf("last pid [%d] \n", this->info->last_pid); } pid8488::get_process_info:entry { this->info = (struct system_info *)copyin(arg0, sizeof(struct system_info)); printf("ncpus [%d] \n", this->info->ncpus); } Running this 55154 get_system_info:entry last pid [8513] 55155 get_process_info:entry ncpus [134558720] Supposed to be showing number of cpus? Anything wrong with the scripting?