From owner-freebsd-scsi@freebsd.org Sun Aug 2 12:22:50 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D59559B0655 for ; Sun, 2 Aug 2015 12:22:50 +0000 (UTC) (envelope-from maxg@mellanox.com) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0084.outbound.protection.outlook.com [157.55.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3431118D for ; Sun, 2 Aug 2015 12:22:49 +0000 (UTC) (envelope-from maxg@mellanox.com) Received: from AM3PR05MB337.eurprd05.prod.outlook.com (10.242.247.143) by AM3PR05MB547.eurprd05.prod.outlook.com (10.242.245.12) with Microsoft SMTP Server (TLS) id 15.1.225.19; Sun, 2 Aug 2015 12:22:41 +0000 Received: from AM3PR05CA010.eurprd05.prod.outlook.com (10.141.192.20) by AM3PR05MB337.eurprd05.prod.outlook.com (10.242.247.143) with Microsoft SMTP Server (TLS) id 15.1.225.19; Sun, 2 Aug 2015 12:22:38 +0000 Received: from DB3FFO11FD021.protection.gbl (2a01:111:f400:7e04::115) by AM3PR05CA010.outlook.office365.com (2a01:111:e400:882a::20) with Microsoft SMTP Server (TLS) id 15.1.225.19 via Frontend Transport; Sun, 2 Aug 2015 12:22:37 +0000 Authentication-Results: spf=pass (sender IP is 193.47.165.134) smtp.mailfrom=mellanox.com; freebsd.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of mellanox.com designates 193.47.165.134 as permitted sender) receiver=protection.outlook.com; client-ip=193.47.165.134; helo=mtlcas13.mtl.com; Received: from mtlcas13.mtl.com (193.47.165.134) by DB3FFO11FD021.mail.protection.outlook.com (10.47.217.52) with Microsoft SMTP Server (TLS) id 15.1.243.9 via Frontend Transport; Sun, 2 Aug 2015 12:22:36 +0000 Received: from MTLCAS13.mtl.com (10.0.8.78) by mtlcas13.mtl.com (10.0.8.78) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sun, 2 Aug 2015 15:22:35 +0300 Received: from MTLCAS01.mtl.com (10.0.8.71) by MTLCAS13.mtl.com (10.0.8.78) with Microsoft SMTP Server (TLS) id 15.0.775.38 via Frontend Transport; Sun, 2 Aug 2015 15:22:35 +0300 Received: from [10.223.0.78] (10.223.0.78) by MTLCAS01.mtl.com (10.0.8.71) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 2 Aug 2015 15:21:41 +0300 Message-ID: <55BE0B55.8070807@mellanox.com> Date: Sun, 2 Aug 2015 15:21:41 +0300 From: Max Gurtovoy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Subject: PIM_UNMAPPED question References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.223.0.78] X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD021; 1:xBREHk8DRzxtDKYvJhNupCpGssqlKdm4NJsV6+nX7Gya1Ti57UgLRqGKBQnn4vqrFuPpvn5+bMd9IuJG+vLFbLiT6pmipBiwblRJYbNb3dWgW+J7OJi/xu3gM0WUgAnkbAG9Zt5olzBfxJz4YwFZ3ArT6sVV/54Y+qdNbGXUsxI3z0Q5U79hjgV9quzqZBg+nJM6uno0IDuoLwQoFgRi6NDpoEcZE9Bh9HVcZl2Xg/R4N9jarUZCF/OtDG9EshUOt8rXvsZivYPwPT+LZeGuIw6mXkKbZOrpVSjtX54de1M= X-Forefront-Antispam-Report: CIP:193.47.165.134; CTRY:IL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(189002)(51874003)(199003)(15975445007)(2950100001)(23746002)(77096005)(80316001)(6806004)(106466001)(62966003)(59896002)(77156002)(36756003)(450100001)(19580395003)(189998001)(33656002)(110136002)(4001350100001)(83506001)(107886002)(2351001)(229853001)(46102003)(92566002)(47776003)(65956001)(65806001)(87936001)(87266999)(76176999)(64126003)(65816999)(54356999)(50986999)(86362001)(50466002)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR05MB337; H:mtlcas13.mtl.com; FPR:; SPF:Pass; MLV:nov; MX:1; A:1; PTR:ErrorRetry; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB337; 2:KLVTjy8vmwNUYArHZCoxtj0gGVysM6j8g1NwclZKdbf9RyD/my+TtsXUfU9iVablZ0m5ZpVyYJ3YCDBe69wcFFzwEnDlg7Zunq0T2Vqt/1Z7+8P8hQqLy7PNxr+vdkVOXNth8M6HsAIUojfoYQRru0pqbQNBkathtJCGl4lbFX8=; 3:SLbot9Dsax6OkjXGYf7WxBdp1Q6bzipLXxKG0l7ILDvXyezeyX/YcA0AJ24AeSH2zmtqziGmYE/qklDlMATb59MTdP8keHG5RFr6qOvDTizfsXNaPORAimz5dJ4/Jeji2gC5Yxw+qjOJmkCq5V/AmGaqePMGZ9hH6wT/5lNmOEX38APt0OyxNxdzfwAaeZ1llutHgytQ6zJ4sJk6TIrMYtaQGkM9+lSMXPKr1p/aGB075BcORsR/nBV+ynHrUks0; 25:FI0OLl5cSjxN4N6/dQ6EwXRBhVQoao4QGl4uk/tPALY/C61fbV4FVs7joxwn3dz69XaSkgvW3+Zbt9kHmzmXRFFJcyOt7NfpsuWwhXXepwyP/6PKic1NyPNaPDHmb8HX+zQeluAiQTaDv91RlO0At+UBeatdZIshwtgHuq+dlt7Vi2Lg5r/DL0Ty42J25rOmtox0q7T9UNe3RBZVxINvVyrtlrsO0Y5E7np8lG6O3CWmeeWEIBOewa6+iX+XXl9hNJ/pljyn16OgMEfqJjILVg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR05MB337; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR05MB547; X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB337; 20:gHpdTryl57+E+/72REczv8SX+zzRq43rzuixts76gYBhiRnxrPPOUyH/RmbKJNKC8uk1PX2nnoybIACUBtpvpeFHTDpff2ejCb85O3IsOd1Y4uTiOGrbPN4PkAnffI/fDg9I5kFPqYb0YAm3d8gFylMZ27S6aN2AwKoIRuGucYuzCgMyRSQ2c3QMBooA68RC58eXKRSlqyXCgzrjCXXOs9raMTz9hYMfVR55KwHZ4DVSNjfaVGJTItAzsCZPG2e3J/zB1AZz8tVaeJycKxO8r3nEjvUph8AMxEWKXI70GU+68bz2kvjPC1oLprNY8jpGurkACxc1Nbwyc56DXrrysfEclg1uUnYHcpn9HkcIdk17uNTVQcSAkTFHqaPrQa4/RQMjmE7GwdmljAcaqdqF9ckrethKIQe9HlAV4sop5JB8Tzxtfy8Xn2icOH8sPY2HbsQ/sV8DVAfpb4OA1mj1zRpPoI0ZX05ZFaXOI8mT1fpSFHnmVdZoqdLAT1MmuXIo; 4:p3dlwpKgJpJB/D3Ru0uE2MkgEQJbx/fpiLbZReQQFCIH2oLf9ZR2lafHqp3JqKqn2hWOM5qSMRg37eA3teEeZxuz9zIUkKGMR4nr5ecIdHy1lFHZ/TmqdjMID0wT2VdIhWvT4B0L3ftsSiqjtDnxkyEi45KOkoSM3/69vCPbvx9dzQa03GB4tnYR5f53/BxwrTYgm6KGDXeesALfSM5k1FeNBSY+fODVYMjqjEOAm1nqClyO4g+iZPnVayDQAoMROGKYlqNKekmhtH96CJMs3CZJnqXyY/4gOeea3NW0FOo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AM3PR05MB337; BCL:0; PCL:0; RULEID:; SRVR:AM3PR05MB337; X-Forefront-PRVS: 0656A4403B X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM3PR05MB337; 23:UCea1FJFHLBBkYgtie4mnr/tsouXtPgsbq44FH?= =?Windows-1252?Q?PczVVrfbltoDqC269Csd+qWVPIk9Kf79E7wJtvprxkcLD5RLLrrALBaa?= =?Windows-1252?Q?zCIsxr8CcU5H8Ak4gvyGT9Z8LmD/riZiTCTs1YRDx+ow3A2T1/bWrqVL?= =?Windows-1252?Q?w9IqKdG6xDx4l6mV0yRV4mI48TRsWol+E4Y29Gdwaks1bsvA0ods55W2?= =?Windows-1252?Q?Yw3aB/Asuc0rlDc3vivd0HY9edSb6t7nTnLD7nLQ9PJeDd8z3JMd589+?= =?Windows-1252?Q?twfD4UX7k/trGELICd/4jdC9H5/9Sjx9J+EpVKoo253SvDRVs23TJZmP?= =?Windows-1252?Q?WsTJkNPCAA2LEPRycSokbfVCWFtOiMXncfEkI2/GmsYEC6IH7FF0PMft?= =?Windows-1252?Q?PTEV5h+TGHqM1U2VjXXI9Y1LVyzFERnrmnfFVE0ozLck+iJ1ATquK5Fj?= =?Windows-1252?Q?0Uyv3Th5eIIY7TPiQeZH57QLPSZKbMUNg9fDXY5j0yRXlq2n+bdmq3Aq?= =?Windows-1252?Q?0rPugP94SKagCygLszTR0leEx0X6ZssGs+lmikHkVsYLx9tIlIR1ZVJ+?= =?Windows-1252?Q?JEtqLRhmbe8GAgHtVbB5c6B6L1q8/fZ1tFco4wROPAMvAsZ0JMr/Q+l5?= =?Windows-1252?Q?kMjrlm2SGGA2HCtU6ofPntkLkHQPITozyfDcHh4P04noLJ+LfeUxIm12?= =?Windows-1252?Q?XraH6lvv7v9mv0XHyaUBXIWwwng0PkKJ+lS4OqGMb5GfBJxCdVb/+Hgn?= =?Windows-1252?Q?JzxT8C/v87n2AXXHFvkpYH9DQ/CfvP7X0LltfsPuu4rk/urxm08zO+09?= =?Windows-1252?Q?DyE138EboP0lQU2SPcuTGmnRCBfvegNnN1WryIIMUuVmQFIolvVA6YIg?= =?Windows-1252?Q?Zmx7xrEomK8tQMBJ7VhgNSFSjaNOoM/IN9KDgEryM8hkL2fVe29emi4a?= =?Windows-1252?Q?69kTCoeCRbbmliR4TlhsQyyXjAJ3VZhKrlRJYOMHOI7RGQbCZzlTsH2o?= =?Windows-1252?Q?9+DJJMoGlxjK19KmOJPsLkdFme7r4KtTGbRrTwjplQDqqgE0vx8y6UyL?= =?Windows-1252?Q?E921p12zL4YTidlGhEmqcQK6RSzA97af5gfn+jS/RkeKN0VNOnRpVrJ2?= =?Windows-1252?Q?cMeYr2/JEXsYhfaZb9IPUTAUGS/wf3JOBnqo6FdMa8?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB337; 5:UDTDWL1atEjmkg7l1yX2mg5+HtDQr7H1gQkjd7xShWvFulI9/PwJ9YTA/dhP7k0D2InWIJgkeFmNcgZA9MHjdpp1OAthQUarFknNWnJswEpThG5dJijxFbZhubQQFNza/S1fEpxfgz18M3b7lI+ruw==; 24:9RPm4TyPhdzm8oGwP68oS9yGyJNt9iZp2O90P5E7y6LmSrbPiyqeuMz5a7RusL7fyGb4ogBpxMI3TNJuPcdW/09Zqn9LE/DoVfbCug1kp28=; 20:BOYRkZnvS7AJYtarTUSPU4yW55iiByGyMoey8LWYdNpGOaoQ2c+QeORhOyocisczF1u0w2LN2UeW2+rDMQ3QvQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2015 12:22:36.4346 (UTC) X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a652971c-7d2e-4d9b-a6a4-d149256f461b; Ip=[193.47.165.134]; Helo=[mtlcas13.mtl.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR05MB337 X-Microsoft-Exchange-Diagnostics: 1; AM3PR05MB547; 2:YgcHj3Btd1kGX3//CrK84mSO+nJrpMbDpHMyy+aBlNxUGve675XAOHakxdNavvySW9MZeW866rLYzd7JbrbtI288TMSvMn3Owt18yZBaWK4SHsB1nZnQV+7EKHUTM2yBmL5KRLEefCJx6+WOznU2jtnBfQbypLMNqQ12Le0bS8c=; 3:WFmfIG7a991UPhtHSk5/SDh9y2KhkUr6l00xG+wcOb/gWgmeuaRJ8E4JrPyKWk0NaYTXg/IdFkQeBMk1RVI3c2byuKgDxYHEmBuutP9JgAJmBgczk7q1FxlkeOSz3sIh2NsUL2P2OzK6FO1tWnCRiyqSbjTrczhtXv7EnajvN+hLjQ4bG5tuBbpipxU4FYiBKjHkzTold6KKvCczBUmPmoU62kU8vlMQq0backO0y1TpNTMUVhQlrwuwW7aHf/UX; 25:st1WgZvbrYvpTfZLmn0PEJ4vVXlQxtuJLuLngpTbCkghVQ4ItPgW52stCEBSTP7vKXqhyX3erHUwny4TY23hBypnfiExwukw7dQjsvvUCqoGFF02XvnuHztPc9K/HS8zIG77xQ6SyM4tcxKEgglMTt75nZRbPeTRhfMnAVfmdnbRCwxrP2GGEY/m4X2uWsEzw1vUiET2JgFl+Qv+YuCK7DpVtLW2iwcn0hiG9NOslLd1JAWWgoVM4ZmBYGc6srwveROzvsWEXlL0KkTyDP3zRQ==; 23:Lt6Kv1DiRrBt3tQPMkuhjPhtg/licVhNJWb0MkQyKA0Q0DARRyL3+u7E7XMzRoACVXoMtzWRVSwOnQXbuBfw3xnylLTlXBlam0NzuikT8ETJWux109HZuWfu/cTIqf90UhbnhFqIzjzNCF+HUOS2TElNF56HTKXHWL5B7yhePRyTH7A3vscGuFgIINltEWjrOtBVOBJQPLkaNfI8VGCmtwy9sfQgjcjvaci8Ge2xSJtHerxyyJMLSerFJ6MEpaTa X-OriginatorOrg: Mellanox.com X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 12:22:50 -0000 Hi, I am working on a new iscsi RDMA transport implementation. In order to avoid kernel buffer allocation in the IO path I added support for unmapped buffers in my driver (PIM_UNMAPPED hba_misc flag). This indeed helped performance by improving the IOPs By a factor of 4x vs. KVAs. However, I noticed that the bio_ma vector consists of physically contiguous addresses. I expected that user-space allocations would not be physically contiguous. Is it possible that I'm still not seeing the user IO buffers? I tested using dd/fio traffic generators and the phenomenon still persists. 128k Read output to show the phenomenon: kernel: dma_address 0x40608000 len 4096 kernel: dma_address 0x40609000 len 4096 kernel: dma_address 0x4060a000 len 4096 kernel: dma_address 0x4060b000 len 4096 kernel: dma_address 0x4060c000 len 4096 kernel: dma_address 0x4060d000 len 4096 kernel: dma_address 0x4060e000 len 4096 kernel: dma_address 0x4060f000 len 4096 kernel: dma_address 0x40610000 len 4096 kernel: dma_address 0x40611000 len 4096 kernel: dma_address 0x40612000 len 4096 kernel: dma_address 0x40613000 len 4096 kernel: dma_address 0x40614000 len 4096 kernel: dma_address 0x40615000 len 4096 kernel: dma_address 0x40616000 len 4096 kernel: dma_address 0x40617000 len 4096 kernel: dma_address 0x40618000 len 4096 kernel: dma_address 0x40619000 len 4096 kernel: dma_address 0x4061a000 len 4096 kernel: dma_address 0x4061b000 len 4096 kernel: dma_address 0x4061c000 len 4096 kernel: dma_address 0x4061d000 len 4096 kernel: dma_address 0x4061e000 len 4096 kernel: dma_address 0x4061f000 len 4096 kernel: dma_address 0x40620000 len 4096 kernel: dma_address 0x40621000 len 4096 kernel: dma_address 0x40622000 len 4096 kernel: dma_address 0x40623000 len 4096 kernel: dma_address 0x40624000 len 4096 kernel: dma_address 0x40625000 len 4096 kernel: dma_address 0x40626000 len 4096 kernel: dma_address 0x40627000 len 4096 Initiator machine info: - OS 11-current r284921 - 32G RAM - 32 Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz CPUs The code is available at: https://github.com/sagigrimberg/iser-freebsd/tree/iser-rebase-11-current-r284921 Thanks in advanced, Max Gurtovoy. From owner-freebsd-scsi@freebsd.org Sun Aug 2 13:39:16 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A1F19B1737 for ; Sun, 2 Aug 2015 13:39:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EAD71B31 for ; Sun, 2 Aug 2015 13:39:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t72DdAgi079195 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 2 Aug 2015 16:39:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t72DdAgi079195 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t72DdAS6079194; Sun, 2 Aug 2015 16:39:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Aug 2015 16:39:10 +0300 From: Konstantin Belousov To: Max Gurtovoy Cc: freebsd-scsi@freebsd.org Subject: Re: PIM_UNMAPPED question Message-ID: <20150802133910.GS2072@kib.kiev.ua> References: <55BE0B55.8070807@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BE0B55.8070807@mellanox.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 13:39:16 -0000 On Sun, Aug 02, 2015 at 03:21:41PM +0300, Max Gurtovoy wrote: > However, I noticed that the bio_ma vector consists of physically > contiguous addresses. I expected that user-space > allocations would not be physically contiguous. Is it possible that I'm > still not seeing the user IO buffers? Large enough userspace allocations, on a machine with enough free or reusable memory, most likely trigger reservations to allow the mappings to be promoted to superpages. This means that on amd64 aligned 2M chunks are often contiguous. You could verify the guess by looking at the procstat(1) -v output for your process. In particular, look for the S flag for the i/o memory mapping. There may be other reasons why you see physically contiguous bio_ma's, but the explanation above is the most straightforward. From owner-freebsd-scsi@freebsd.org Mon Aug 3 12:50:55 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 305429B222E for ; Mon, 3 Aug 2015 12:50:55 +0000 (UTC) (envelope-from bah@bananmonarki.se) Received: from feeder.usenet4all.se (1-1-1-38a.far.sth.bostream.se [82.182.32.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 910F01881 for ; Mon, 3 Aug 2015 12:50:52 +0000 (UTC) (envelope-from bah@bananmonarki.se) Received: from testbox.news4all.se (testbox.usenet4all.se [10.0.0.3]) by feeder.usenet4all.se (8.13.1/8.13.1) with ESMTP id t73CognD046906 for ; Mon, 3 Aug 2015 14:50:42 +0200 (CEST) (envelope-from bah@bananmonarki.se) Message-ID: <55BF63A2.6060909@bananmonarki.se> Date: Mon, 03 Aug 2015 14:50:42 +0200 From: Bernt Hansson User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "freebsd-scsi@freebsd.org" Subject: USB stick and some help with it. Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 12:50:55 -0000 Hello list. Have an old usbstick that i bought 5-6 years ago it's a datatraveler 150. I used dd to transfer a cd image to it and now i can't "clean" it of the stick. Tried dd if=/dev/random of=/dev/da1 bs=1m count=100 but dd just taunting me with this: dd: /dev/da1: Input/output error 1+0 records in 0+0 records out 0 bytes transferred in 65.558710 secs (0 bytes/sec) After that the led on the stick flashes like it is writing. But i don't know if it is writing. Is it possible to make it pristine again or is it forever lost? From owner-freebsd-scsi@freebsd.org Mon Aug 3 19:43:44 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE79F9B2E3E for ; Mon, 3 Aug 2015 19:43:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEAC3119A for ; Mon, 3 Aug 2015 19:43:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t73Jhfl2014242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2015 12:43:41 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t73JhfdU014241; Mon, 3 Aug 2015 12:43:41 -0700 (PDT) (envelope-from jmg) Date: Mon, 3 Aug 2015 12:43:41 -0700 From: John-Mark Gurney To: Bernt Hansson Cc: "freebsd-scsi@freebsd.org" Subject: Re: USB stick and some help with it. Message-ID: <20150803194340.GF78154@funkthat.com> References: <55BF63A2.6060909@bananmonarki.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BF63A2.6060909@bananmonarki.se> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 03 Aug 2015 12:43:41 -0700 (PDT) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:43:45 -0000 Bernt Hansson wrote this message on Mon, Aug 03, 2015 at 14:50 +0200: > Have an old usbstick that i bought 5-6 years ago it's a datatraveler 150. > > I used dd to transfer a cd image to it and now i can't "clean" it of the > stick. > > Tried dd if=/dev/random of=/dev/da1 bs=1m count=100 but dd just taunting > me with this: > > dd: /dev/da1: Input/output error > 1+0 records in > 0+0 records out > 0 bytes transferred in 65.558710 secs (0 bytes/sec) > > After that the led on the stick flashes like it is writing. But i don't > know if it is writing. > > Is it possible to make it pristine again or is it forever lost? Do you get any consol error messages? I was thinking it might be because there was a partition or something mounted, but I don't think that's the case, as it should have given you an Operation not permitted error instead... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-scsi@freebsd.org Wed Aug 5 17:52:19 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B278F9B3A22 for ; Wed, 5 Aug 2015 17:52:19 +0000 (UTC) (envelope-from sibananda.sahu@avagotech.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59A42951 for ; Wed, 5 Aug 2015 17:52:19 +0000 (UTC) (envelope-from sibananda.sahu@avagotech.com) Received: by wicne3 with SMTP id ne3so14564443wic.1 for ; Wed, 05 Aug 2015 10:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=avagotech.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=UWEXMf1vuXa+GmsNjbPXYfOMVuoz6QsZ4J3hRu5611w=; b=CEnDYdKPQg0rjktjJSxNTNAlDN7K6332+GqSNDI6Bge+2nnhbwQ64sF/6WYGVFXRVL QGEqZX4KPI3xGDwg9PDN/C7WbAA8O98AIWkuSszBQuIDbznDZv9EHkbfJEImaAD/pIzM C3uSJTA42CHajUygCW6bK4QWrHa/Ze2WlLcmg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=UWEXMf1vuXa+GmsNjbPXYfOMVuoz6QsZ4J3hRu5611w=; b=H9h6u5xDFqY2I+st5JYFbrLun/04ISVxLtWKXF6qF0/JV+3t/UIiEhYUcgIoBuwQoA TiMq+smTpke8gaaS2yR3UnlfXqr3ZjgkFoy9eqoPBjXd4qcPSRrmsfeEsFxi/WU+us7+ K/3YTwSv75NsmXWfbTGoWzCzJs6cVSG0r60MWydgackz478d8jmnEyf0j66u+V+rWcrH 2stjHT+egLbkzjwzuwIDWEhBt3UVaIj4GUK5Ru6FpzpTguAcEFYji98XgciyP30ls5ih 7/YfGMBudqqbXFRur3XAH7YWOPO6gF+zsuRiVhUAo3jYHQAd55X4pWxas17EBHigHhBG Msrg== X-Gm-Message-State: ALoCoQlNWfpkMfv+1U0vPmvnAoXs941pduujrxiSo/2isHqAc6iJ1DWYzgj0t88WbfkLbQukllW+ X-Received: by 10.180.91.79 with SMTP id cc15mr820066wib.53.1438797137629; Wed, 05 Aug 2015 10:52:17 -0700 (PDT) From: Sibananda Sahu MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDPp3cjbM/DUu3nTL66kDjhTM9oIA== Date: Wed, 5 Aug 2015 23:22:15 +0530 Message-ID: Subject: Max queue depth per target device??? To: freebsd-scsi@freebsd.org Cc: "Kenneth D. Merry" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:52:19 -0000 Hi All, Is the CAM layer provides per target queue depth setting? If yes then can anybody tell me how to implement that in the SIM driver? Or, if no, then is there any proposal to implement per target queue depth in FreeBSD CAM layer, similar to that of the Linux SCSI sub-system? Sibananda Sahu From owner-freebsd-scsi@freebsd.org Wed Aug 5 18:14:32 2015 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22CA09B3F93 for ; Wed, 5 Aug 2015 18:14:32 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm30.bullet.mail.gq1.yahoo.com (nm30.bullet.mail.gq1.yahoo.com [98.136.217.13]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E72EA13B7 for ; Wed, 5 Aug 2015 18:14:31 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1438798071; bh=92mH/g3tbkFn3oVsAmGk8sHABBLG1Q0nqejtmBF4MPU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=heRnwFASEnh+4KD7AXaT54eznvxBtnWy0PAo6Gxn8PiTlk0fxKNZNbtBz2TktrCjosFU0lopxQhon4pBVbQnpyBw6IVCtzwun/+kFPaAsEmRvimeDDt3ikUL/bye2dRjBC15jHQ0vksuJOYn5uPQY47krUF40Ibmwpo/YOctaoOg3RPXi4mR9tNFD1r8jR8q1LIVTJAZ4zgQCNf1cMFF6g5stqxZREa3lom3YYGatk2X5Y7vPl/K0SuyvTRKoPYUCZyAAseWMhSKyNLE2dHnFi0dNNbB+VxgGUUOQah0djbZE87uw6V6IrXCxkNs2RmjbZvNSEH6jgw3o2chwzl33Q== Received: from [98.137.12.63] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 05 Aug 2015 18:07:51 -0000 Received: from [208.71.42.209] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 05 Aug 2015 18:07:51 -0000 Received: from [127.0.0.1] by smtp220.mail.gq1.yahoo.com with NNFMP; 05 Aug 2015 18:07:51 -0000 X-Yahoo-Newman-Id: 688091.12057.bm@smtp220.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2jxUPNIVM1kzUxrwL8JmCmFol0UE7XMeQUzHBkkIU3NrdQT BTzOus6mMYmfzecYIGAqk6gDvG3ctXiGu8TGFuKtlQxYO_jKL_KF6uk7C.ZM _fn7geC5zDgJTo7JY4VHJSGLzLR8bzNaQDbKmBr0xTo55aY6JGWWwULhOTnN ET4JprRtlugw61Tdhr6FYWx.T4Hj34Mq44M0NhyE9DP8yKN87r4UozfSqqQN env6iCZthaL9biF2IhXkmJa_8UzN4v6jgDCI6isBd7XDLI6TiZc3NEVqLfQL yqeUhQbUU.HEznQjEt95FD.VQ.JiRXD_LcAFgYUe_dJjFy3wOGyHycbMKuBw 4Yk6kZFi5lJUjTM5JRaGC0Z_GfsLGJtJzU1OcCmr7hfawmDdmR2ezwhveA7S 7Pp2ktGkgrlEbUa1U4Yo4Cs_a4YF5t0VV1rc1zLABz3dysbgwounF16mmP8L 2XPNfXab6xdyHnGHd1CjRf7HaYhmHjH4NtFLm9bLel52fenjtbx8JkB_NU09 IgL.4dyyIOWzGkW.GAOxjqolIV248sIKY5HoLvCRj X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Max queue depth per target device??? From: Scott Long In-Reply-To: Date: Wed, 5 Aug 2015 12:07:49 -0600 Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" Content-Transfer-Encoding: quoted-printable Message-Id: <07949D93-5098-49EE-9D1A-95729269716B@yahoo.com> References: To: Sibananda Sahu X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 18:14:32 -0000 > On Aug 5, 2015, at 11:52 AM, Sibananda Sahu via freebsd-scsi = wrote: >=20 > Hi All, >=20 >=20 >=20 > Is the CAM layer provides per target queue depth setting? >=20 > If yes then can anybody tell me how to implement that in the SIM = driver? >=20 > Or, if no, then is there any proposal to implement per target queue = depth > in FreeBSD CAM layer, similar to that of the Linux SCSI sub-system? >=20 For the SATA transport, CAM takes care of probing the SATA NCQ register = and setting the appropriate queue depth. For the SCSI transport, CAM assumes that the drives will continue to = take commands until they are full, and then will report a QUEUE_FULL = status. When CAM gets that status, it adjusts the queue depth = automatically. So no, there are no plans to set a simple static value like in Linux. = CAM probes for it automatically, so long as the driver passes the QUEUE = FULL status up correctly. Scott