From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 2 15:06:28 2012 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9AB4106564A; Sun, 2 Sep 2012 15:06:28 +0000 (UTC) (envelope-from nyan@FreeBSD.org) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6FB8FC15; Sun, 2 Sep 2012 15:06:28 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id q82F6Okx068537; Mon, 3 Sep 2012 00:06:26 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Mon, 03 Sep 2012 00:06:24 +0900 (JST) Message-Id: <20120903.000624.343708041257771253.nyan@FreeBSD.org> To: jhb@freebsd.org From: TAKAHASHI Yoshihiro In-Reply-To: <201208311430.32959.jhb@freebsd.org> References: <201208311430.32959.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: non@freebsd.org, scsi@freebsd.org Subject: Re: [PATCH] Convert scsi_low from timeout(9) to callout(9) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 15:06:29 -0000 In article <201208311430.32959.jhb@freebsd.org> John Baldwin writes: > Also, it still has > a lot of compat shims to work on NetBSD. I can't seem to find a scsi_low.c on > NetBSD at all anymore. Do we still need NetBSD compat shims? If not, > trimming those would make this code far more readable. The scsi_low was developed by NetBSD/pc98 team to reduce duplicate code between scsi drivers. NetBSD/pc98 was developed on a separate tree and not merged into the NetBSD tree. Now NetBSD/pc98 is not developed anymore, so I think we may remove NetBSD part from scsi_low. --- TAKAHASHI Yoshihiro From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 3 11:09:58 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7AE9106566C for ; Mon, 3 Sep 2012 11:09:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 916D08FC19 for ; Mon, 3 Sep 2012 11:09:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q83B9wdP051253 for ; Mon, 3 Sep 2012 11:09:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83B9ujk050872 for freebsd-scsi@FreeBSD.org; Mon, 3 Sep 2012 11:09:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2012 11:09:56 GMT Message-Id: <201209031109.q83B9ujk050872@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 11:09:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/169976 scsi [cam] [patch] make scsi_da use sysctl values where app o kern/169974 scsi [cam] [patch] add Quirks for SSD that are 4k optimised o kern/169835 scsi [patch] remove some unused variables from scsi_da prob o kern/169801 scsi [cam] [patc] make changes to delete_method in scsi_da o kern/169403 scsi [cam] [patch] CAM layer, I/O starvation, no fairness o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free o kern/163713 scsi [aic7xxx] [patch] Add Adaptec29329LPE to aic79xx_pci.c o kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o kern/161809 scsi [cam] [patch] set kern.cam.boot_delay via build option o kern/159412 scsi [ciss] 7.3 RELEASE: ciss0 ADAPTER HEARTBEAT FAILED err o kern/157770 scsi [iscsi] [panic] iscsi_initiator panic o kern/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153514 scsi [cam] [panic] CAM related panic o kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 55 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 3 12:47:13 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483191065778; Mon, 3 Sep 2012 12:47:13 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0363A8FC16; Mon, 3 Sep 2012 12:47:12 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1T8W1C-0001sD-96; Mon, 03 Sep 2012 13:44:42 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T8W1B-0001eC-Mu; Mon, 03 Sep 2012 13:44:41 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q83Cif2P073866; Mon, 3 Sep 2012 13:44:41 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q83CifEt073865; Mon, 3 Sep 2012 13:44:41 +0100 (BST) (envelope-from mexas) Date: Mon, 3 Sep 2012 13:44:41 +0100 (BST) From: Anton Shterenlikht Message-Id: <201209031244.q83CifEt073865@mech-cluster241.men.bris.ac.uk> To: marius@alchemy.franken.de, mav@freebsd.org In-Reply-To: <20120821103332.GA89798@alchemy.franken.de> Cc: freebsd-scsi@freebsd.org Subject: Re: can't use cdrecord on -current - lots of warnigs, possible ATA_CAM issue? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 12:47:13 -0000 From marius@alchemy.franken.de Tue Aug 21 12:10:36 2012 On Sat, Jul 21, 2012 at 07:15:00PM +0300, Alexander Motin wrote: > On 17.07.2012 18:13, Anton Shterenlikht wrote: > >I thought this was a sparc64 issue, > >but marius@ advised to ask for help > >in this list. > > > >I've rebuild sysutils/cdrecord (I also tried sysutils/cdrecord-devel) > >multiple times. > > > >Thanks > > > >----- Forwarded message from Anton Shterenlikht ----- > > > > > ># uname -a > >FreeBSD mech-anton240.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #6 > >r235474: Tue Jul 17 13:52:07 BST 2012 > >root@mech-anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/QOF sparc64 > ># > > > >After updating to ATA_CAM framework > >I cannot use cdrecord: > > > ># cdrecord -dev=1,0,0 -sao /home/mexas/FreeBSD-8.1-RELEASE-ia64-livefs.iso > >Cdrecord-ProDVD-ProBD-Clone 3.01a07 (sparc64-unknown-freebsd10.0) > >Copyright (C) > >1995-2012 Joerg Schilling > >scsidev: '1,0,0' > >scsibus: 1 target: 0 lun: 0 > >Using libscg version 'schily-0.9'. > >Device type : Removable CD-ROM > >Version : 0 > >Response Format: 2 > >Capabilities : > >Vendor_info : 'TSSTcorp' > >Identifikation : 'CDW/DVD TS-H492C' > >Revision : 'SI00' > >Device seems to be: Generic mmc2 DVD-ROM. > >cdrecord: Warning: controller returns zero sized CD write parameter page. > >cdrecord: Warning: controller returns wrong size for CD write parameter > >page. > >cdrecord: Warning: controller returns wrong page 0 for CD write parameter > >page ( > >5). > >Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > >Driver flags : MMC-3 SWABAUDIO BURNFREE > >Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R > >cdrecord: Warning: Cannot read drive buffer. > >cdrecord: Warning: The DMA speed test has been skipped. > >resid: 2 > >resid: 24 > >DMA overrun, resid: -24 > >resid: 30 > >cdrecord: Warning: controller returns zero sized CD write parameter page. > >cdrecord: Warning: controller returns wrong size for CD write parameter > >page. > >cdrecord: Warning: controller returns wrong page 0 for CD write parameter > >page ( > >5). > >cdrecord: Warning: controller returns zero sized CD write parameter page. > >cdrecord: Warning: controller returns wrong size for CD write parameter > >page. > >cdrecord: Warning: controller returns wrong page 0 for CD write parameter > >page ( > >5). > >cdrecord: Cannot init drive. > ># > > > > > >while on the console: > > > > > >ata3: unknown transfer phase > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - MODE_SENSE_BIG read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 60>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 10>0 > >ata3: WARNING - READ_BUFFER read data overrun 4>0 > >ata3: WARNING - START_STOP read data overrun 18>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 16>0 > >ata3: WARNING - READ_CAPACITY read data overrun 8>0 > >ata3: WARNING - READ_TOC read data overrun 4>0 > >ata3: WARNING - READ_TOC read data overrun 2>0 > >ata3: WARNING - READ_DISK_INFO read data overrun 4>0 > >ata3: WARNING - READ_DISK_INFO read data overrun 4>0 > >ata3: WARNING - READ_DISK_INFO read data overrun 4>0 > >ata3: WARNING - READ_DISK_INFO read data overrun 4>0 > >ata3: WARNING - READ_DISK_INFO read data overrun 4>0 > >ata3: WARNING - READ_DISK_INFO read data overrun 4>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 34>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 10>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 2>0 > >ata3: WARNING - TEST_UNIT_READY read data overrun 10>0 > >ata3: WARNING - SYNCHRONIZE_CACHE read data overrun 2>0 > > > > > ># dmesg|grep cd0 > >cd0 at ata3 bus 0 scbus1 target 0 lun 0 > >cd0: Removable CD-ROM SCSI-0 device > >cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > >cd0: Attempt to query device size failed: NOT READY, Medium not present - > >tray c > >losed > ># > > I can't reproduce your problem on my Sun Blade 100. I've fixed two other > problems in ata(4) I've found in process (r238666 and r238673) and now I > can successfully record CD with both cdrtools and cdrtools-devel. > Thanks a lot! Could you please MFC these fixes to 8/9/9.1 as apparently r238666 affects all and r238673 at least all !x86 architectures and not just sparc64? Also, could you please look into why ATA_CAM breaks ATAPI CAM/ causes data corruption for/with certain controllers driven by ata(4)? At least the the ALi ATA controller in Blade 100, which AFAIK you own one of, is affected, but again, this problem is also seen with ITE ones on x86. Marius I updated to r239940, and now the cdrom seems to work ok. I can mount cds and burn with cdrtools-devel-3.01a08,1. This is on cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) Many thanks Anton From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 5 09:45:47 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 224DC106566B for ; Wed, 5 Sep 2012 09:45:47 +0000 (UTC) (envelope-from penta1998@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4048FC14 for ; Wed, 5 Sep 2012 09:45:46 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so313528lbb.13 for ; Wed, 05 Sep 2012 02:45:45 -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=GMkIjnRLqpuzpAxgqPbYiXyMpZEx4nr1zjQZGO39+gw=; b=EFTga+gI9njRS3hIC/znojTPRndrvSM4yGfOKPszsN+iDXlIIqEJ/IhKlQ1D3v3S/3 P4fn75ECdYYjt+5wFxtM/hpXR0IMq44ZPaT5qn91q1zicLK1knAippaU0nhcxmwPqV6r bA8MrNFH4hkl11A5R54f/8Ot1NP9m8jVI+3TrxTNqFKJ1vjyS8RnObGIB/1YHk0IO6a+ 5kZrFbP01KnucCjM3eMX8mm/aMZlJAAt/65nDYohBHWPJhkwhHhLzPKW3WSIzoSy2Teg x/sZJ5P7ts9oyw5KEQF6oScCdzaBkBmA9vao6xEgL12E9Joe/gx7d4JG+/4b0o8G0y0L I33w== MIME-Version: 1.0 Received: by 10.112.27.232 with SMTP id w8mr2818508lbg.77.1346838344970; Wed, 05 Sep 2012 02:45:44 -0700 (PDT) Received: by 10.114.21.135 with HTTP; Wed, 5 Sep 2012 02:45:44 -0700 (PDT) Date: Wed, 5 Sep 2012 15:15:44 +0530 Message-ID: From: Penta To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: isp 24xx target-mode SRR handling X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:45:47 -0000 Hi Matthew, I'm trying to understand the target-mode implementation of the isp driver. My question is regarding SRR handling. On receiving a notify request IN24XX_SRR_RCVD, it seems that the target rejects the notify request (na_srr_flags = 1, na_srr_reject_flags = 1 etc.. which i dont understand) My question is that shouldn't the initiator send a SRR request only when data retransmission is supported by the target (in isp's case it isn't). The PRLI handling doesn't seem to do anything w.r.t to SRR. How does the target notify the initiator that retransmission isn't supported ? Also what happens next, does the initiator retry the entire command, or is it dependent on the initiator implementation ? Is an SRR implementation for target-mode vital moving forward (8GB cards etc.) or is it just a nice to have feature ? I am new with the FC protocol and the code. I might have asked something obvious, so please bear with me. Thank You From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 5 13:57:53 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C053D1065676 for ; Wed, 5 Sep 2012 13:57:53 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7403D8FC21 for ; Wed, 5 Sep 2012 13:57:53 +0000 (UTC) Received: from [192.168.135.101] (c-24-5-173-152.hsd1.ca.comcast.net [24.5.173.152]) (authenticated bits=0) by ns1.feral.com (8.14.5/8.14.4) with ESMTP id q85Dvjb0044372 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 06:57:46 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <50475A54.5000804@feral.com> Date: Wed, 05 Sep 2012 06:57:40 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Wed, 05 Sep 2012 06:57:46 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: isp 24xx target-mode SRR handling X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matt Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:57:53 -0000 On 9/5/2012 2:45 AM, Penta wrote: > Hi Matthew, > > I'm trying to understand the target-mode implementation of the isp driver. > My question is regarding SRR handling. On receiving a notify request > IN24XX_SRR_RCVD, it seems that the target rejects the notify request > (na_srr_flags = 1, na_srr_reject_flags = 1 etc.. which i dont understand) > > My question is that shouldn't the initiator send a SRR request only when > data retransmission is supported by the target (in isp's case it isn't). > The PRLI handling doesn't seem to do anything w.r.t to SRR. How does the > target notify the initiator that retransmission isn't supported ? Also what > happens next, does the initiator retry the entire command, or is it > dependent on the initiator implementation ? > > Is an SRR implementation for target-mode vital moving forward (8GB cards > etc.) or is it just a nice to have feature ? > > I am new with the FC protocol and the code. I might have asked something > obvious, so please bear with me. > Yes, the initiator is only going to send an SRR to devices that have set in the PRLI word3 that they support that. Note also that isp(8) is cognizant about this for it's initiator side as well. It's been supported in the QLogic cards for quite some time, but not in isp(8). That setting is done in isp_fibre_init_2400 by looking at options gotten from card NVRAM, looking at softer setting options and setting the value in the ICB (init control block) and local softc appropriately: icbp->icb_fwoptions2 = fcp->isp_xfwoptions; if (isp->isp_confopts & ISP_CFG_NOFCTAPE) { icbp->icb_fwoptions2 &= ~ICB2400_OPT2_FCTAPE; } if (isp->isp_confopts & ISP_CFG_FCTAPE) { icbp->icb_fwoptions2 |= ICB2400_OPT2_FCTAPE; } if (icbp->icb_fwoptions2 & ICB2400_OPT2_FCTAPE) { FCPARAM(isp, chan)->fctape_enabled = 1; } else { FCPARAM(isp, chan)->fctape_enabled = 0; } and in isp_fiber_init (for 23XX cards); if (ISP_CAP_FCTAPE(isp)) { if (isp->isp_confopts & ISP_CFG_NOFCTAPE) icbp->icb_xfwoptions &= ~ICBXOPT_FCTAPE; if (isp->isp_confopts & ISP_CFG_FCTAPE) icbp->icb_xfwoptions |= ICBXOPT_FCTAPE; if (icbp->icb_xfwoptions & ICBXOPT_FCTAPE) { icbp->icb_fwoptions &= ~ICBOPT_FULL_LOGIN; /* per documents */ icbp->icb_xfwoptions |= ICBXOPT_FCTAPE_CCQ|ICBXOPT_FCTAPE_CONFIRM; FCPARAM(isp, 0)->fctape_enabled = 1; } else { FCPARAM(isp, 0)->fctape_enabled = 0; } } else { icbp->icb_xfwoptions &= ~ICBXOPT_FCTAPE; FCPARAM(isp, 0)->fctape_enabled = 0; } What the initiator does after the SRR depends on what the target does. The idea of sending an SRR is to let the target know that you didn't quite get what they were sending. In the case of lost data, the SRR causes a reset of the SCSI protocol data pointer so that data retransmission begins again from the reset data pointer offset. In the case of a lost RSPNS frame, the response frame is just resent. There are some subtleties about the practical aspects of current implementations that make things a little difficult. For example you're not likely to know you've lost a frame until the RSPNS frame is sent (for reads from the target), and as you may or may not have noticed this causes some complications with the current CAM state machine notion- by the time you're told that a frame was lost, the SIM has no idea what to do because that relates to a CTIO that was done some time in the past (hence the current CAM_RECV_MESSAGE hack). If you want to see all of the ins and outs of data recovery cases related to SRR and other mechanisms, you should read FCP2 (probably not available w/o being a t10 member) or FCP4 (available from www.t10.org I think because it's still in draft form) which goes on at great length about recovery mechanisms. From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 5 18:41:45 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9928D106564A for ; Wed, 5 Sep 2012 18:41:45 +0000 (UTC) (envelope-from penta1998@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0141F8FC12 for ; Wed, 5 Sep 2012 18:41:44 +0000 (UTC) Received: by lage12 with SMTP id e12so731442lag.13 for ; Wed, 05 Sep 2012 11:41:43 -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=6D1RG3nyrcbV5SXKM+TCL5b3Io2Li4kQdGN/8JsNEr8=; b=C6CN0WZdniiVEHTbKY/0rvs5yHg85quWWPkto4EA/jyqr5F+OmeTvwafHFzHoqjn4L uQ5TKUQFOiwO9iA8hatvGY1dXj2WoornGwxhnNVZ0/ZY9AkdNSgdrdyWE8iiI386V2wD Q/GoisjUcjQBMs2Mk3+z5R4i/kxr/YeqeZBFWwbcm6vHyWkOt6d+N2bMQpdNsMkscBnQ h3NriRmqkq1MA3PGQXlwPXZJt2ZRq3ygwB+YXmJ5VDsPpoY3rw0oy25xKey4wqBWEjsU rHSvo6UaRGNTCFiQ+t7KyfwYls/Y/R2Q2Ocg9Hu3eUETMHh8wpYHiIidXGZFBlkRtDBN 60ZA== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr21066652lab.45.1346870503598; Wed, 05 Sep 2012 11:41:43 -0700 (PDT) Received: by 10.114.21.135 with HTTP; Wed, 5 Sep 2012 11:41:43 -0700 (PDT) In-Reply-To: <50475A54.5000804@feral.com> References: <50475A54.5000804@feral.com> Date: Thu, 6 Sep 2012 00:11:43 +0530 Message-ID: From: Penta To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: isp 24xx target-mode SRR handling X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:41:45 -0000 Hi Matthew, Thanks, things are much more clear to me. I also came across your commit description at http://svnweb.freebsd.org/base?view=revision&revision=238869which helped. My sources were a bit outdated and didn't have the SRR/FC Tape changes. Now that i have them, i'm back to my reading :-) Thanks a lot once again. On Wed, Sep 5, 2012 at 7:27 PM, Matthew Jacob wrote: > On 9/5/2012 2:45 AM, Penta wrote: > >> Hi Matthew, >> >> I'm trying to understand the target-mode implementation of the isp driver. >> My question is regarding SRR handling. On receiving a notify request >> IN24XX_SRR_RCVD, it seems that the target rejects the notify request >> (na_srr_flags = 1, na_srr_reject_flags = 1 etc.. which i dont understand) >> >> My question is that shouldn't the initiator send a SRR request only when >> data retransmission is supported by the target (in isp's case it isn't). >> The PRLI handling doesn't seem to do anything w.r.t to SRR. How does the >> target notify the initiator that retransmission isn't supported ? Also >> what >> happens next, does the initiator retry the entire command, or is it >> dependent on the initiator implementation ? >> >> Is an SRR implementation for target-mode vital moving forward (8GB cards >> etc.) or is it just a nice to have feature ? >> >> I am new with the FC protocol and the code. I might have asked something >> obvious, so please bear with me. >> >> Yes, the initiator is only going to send an SRR to devices that have set > in the PRLI word3 that they support that. Note also that isp(8) is > cognizant about this for it's initiator side as well. It's been supported > in the QLogic cards for quite some time, but not in isp(8). > > That setting is done in isp_fibre_init_2400 by looking at options gotten > from card NVRAM, looking at softer setting options and setting the value in > the ICB (init control block) and local softc appropriately: > > icbp->icb_fwoptions2 = fcp->isp_xfwoptions; > if (isp->isp_confopts & ISP_CFG_NOFCTAPE) { > icbp->icb_fwoptions2 &= ~ICB2400_OPT2_FCTAPE; > } > if (isp->isp_confopts & ISP_CFG_FCTAPE) { > icbp->icb_fwoptions2 |= ICB2400_OPT2_FCTAPE; > } > > if (icbp->icb_fwoptions2 & ICB2400_OPT2_FCTAPE) { > FCPARAM(isp, chan)->fctape_enabled = 1; > } else { > FCPARAM(isp, chan)->fctape_enabled = 0; > } > > and in isp_fiber_init (for 23XX cards); > > if (ISP_CAP_FCTAPE(isp)) { > if (isp->isp_confopts & ISP_CFG_NOFCTAPE) > icbp->icb_xfwoptions &= ~ICBXOPT_FCTAPE; > > if (isp->isp_confopts & ISP_CFG_FCTAPE) > icbp->icb_xfwoptions |= ICBXOPT_FCTAPE; > > if (icbp->icb_xfwoptions & ICBXOPT_FCTAPE) { > icbp->icb_fwoptions &= ~ICBOPT_FULL_LOGIN; > /* per documents */ > icbp->icb_xfwoptions |= > ICBXOPT_FCTAPE_CCQ|ICBXOPT_**FCTAPE_CONFIRM; > FCPARAM(isp, 0)->fctape_enabled = 1; > } else { > FCPARAM(isp, 0)->fctape_enabled = 0; > } > } else { > icbp->icb_xfwoptions &= ~ICBXOPT_FCTAPE; > FCPARAM(isp, 0)->fctape_enabled = 0; > } > > What the initiator does after the SRR depends on what the target does. The > idea of sending an SRR is to let the target know that you didn't quite get > what they were sending. In the case of lost data, the SRR causes a reset of > the SCSI protocol data pointer so that data retransmission begins again > from the reset data pointer offset. In the case of a lost RSPNS frame, the > response frame is just resent. > > There are some subtleties about the practical aspects of current > implementations that make things a little difficult. For example you're not > likely to know you've lost a frame until the RSPNS frame is sent (for reads > from the target), and as you may or may not have noticed this causes some > complications with the current CAM state machine notion- by the time you're > told that a frame was lost, the SIM has no idea what to do because that > relates to a CTIO that was done some time in the past (hence the current > CAM_RECV_MESSAGE hack). > > If you want to see all of the ins and outs of data recovery cases related > to SRR and other mechanisms, you should read FCP2 (probably not available > w/o being a t10 member) or FCP4 (available from www.t10.org I think > because it's still in draft form) which goes on at great length about > recovery mechanisms. > > > ______________________________**_________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@**freebsd.org > " >