From owner-freebsd-stable@FreeBSD.ORG Wed Oct 3 23:52:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DF97106566C for ; Wed, 3 Oct 2012 23:52:05 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3928FC0A for ; Wed, 3 Oct 2012 23:52:04 +0000 (UTC) Received: by weyx43 with SMTP id x43so5534400wey.13 for ; Wed, 03 Oct 2012 16:52:04 -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=qqYGuNvEBkISwCg7enT+xqlpanMiDR5li0G+yaShKOM=; b=VLN3IopIZXqbeG+CK7niDl2nzXhTUY3FnL3azquJb3lbpasMFJflQCGq+yIy4yrfn0 5ugQLqRIOY/nKUN89aCRC7JAkq6NDITMDp+W/Q1TmFppXlpik6X2hW/y2lK7d5tWUMq8 F02qj8kKCDGZ3rt0Qt2Esz1J8YI1lC1sE5/z+QsUquYQEFly1wwMjfLkIYgLGQ2FYBge rttT1XejAnLscfM5H6juwTEztM1RxIutJATR8HqcpztUqtaSA508Pvg1uP5yHmV0O84H /xLGCLKki9/lYfO22WPkaK9JZ3hNZTP6LSdPH3JXj7w67ltvu1GJviIlSkpM7rCS+S1M kPAA== MIME-Version: 1.0 Received: by 10.180.87.42 with SMTP id u10mr8319119wiz.0.1349308323926; Wed, 03 Oct 2012 16:52:03 -0700 (PDT) Received: by 10.216.143.134 with HTTP; Wed, 3 Oct 2012 16:52:03 -0700 (PDT) In-Reply-To: <11028C2E-9DB0-4B71-A7B1-98160D5AEA93@gmail.com> References: <72A4B763-D36B-4912-8C20-7373A0562EA1@gmail.com> <11028C2E-9DB0-4B71-A7B1-98160D5AEA93@gmail.com> Date: Wed, 3 Oct 2012 16:52:03 -0700 Message-ID: From: Chuck Tuffli To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" Subject: Re: CAM Target Layer and Linux (continued) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 23:52:05 -0000 On Tue, Oct 2, 2012 at 3:03 AM, Nikolay Denev wrote: > > On Sep 27, 2012, at 6:33 PM, Nikolay Denev wrote: > >> Hi All, >> >> With the help of Chuck Tuffli, I'm now able to use CTL to export a zvol over FC to a Linux host: >> >> LUN Backend Size (Blocks) BS Serial Number Device ID >> 0 block 4185915392 512 FBSDZFS001 ORA_ASM_01 >> lun_type=0 >> num_threads=14 >> file=/dev/zvol/tank/oracle_asm_01 >> 1 block 4185915392 512 FBSDZFS002 ORA_ASM_02 >> lun_type=0 >> num_threads=14 >> file=/dev/zvol/tank/oracle_asm_02 >> 2 block 4185915392 512 FBSDZFS003 ORA_ASM_03 >> lun_type=0 >> num_threads=14 >> file=/dev/zvol/tank/oracle_asm_03 >> 3 block 4185915392 512 FBSDZFS004 ORA_ASM_04 >> lun_type=0 >> num_threads=14 >> file=/dev/zvol/tank/oracle_asm_04 >> >> Then we ran some tests using Oracle's ORION benchmark tool from the Linux host. >> We ran one test which passed successfully, >> then I've just disabled zfs prefetch -> "vfs.zfs.prefetch_disable=1" >> and rerun the test, which failed due to this error. >> >> On the FreeBSD side: >> >> (0:3:0:1): READ(10). CDB: 28 0 84 f9 58 0 0 4 0 0 >> (0:3:0:1): Tag: 0x116220, Type: 1 >> (0:3:0:1): CTL Status: SCSI Error >> (0:3:0:1): SCSI Status: Check Condition >> (0:3:0:1): SCSI sense: NOT READY asc:4b,0 (Data phase error) ... > After a whole day of orion tests without problems, we started an Oracle ASM instance from the Linux host and > again got an error, this time it was WRITE error : > > (0:3:0:3): WRITE(10). CDB: 2a 0 1 5b 10 0 0 4 0 0 > (0:3:0:3): Tag: 0x110940, Type: 1 > (0:3:0:3): CTL Status: SCSI Error > (0:3:0:3): SCSI Status: Check Condition > (0:3:0:3): SCSI sense: NOT READY asc:4b,0 (Data phase error) > > I've tried to track down this "Data phase error" in the CTL code and it looks like it is something related to the isp(4) driver: This would have been my first guess if there had been something in the logs from isp, but since there wasn't, it's hard to tell. I been running orion for ~3hrs now with a different FC driver + an analyzer but haven't seen this problem. Would it be possible to stick some prints in default clause of the ctlfedone() to confirm if this is front or back end problem? Especially interesting would be the value of done_ccb->ccb_h.status. ---chuck