From owner-freebsd-scsi@FreeBSD.ORG Sun Mar 14 19:49:44 2010 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 34D78106564A for ; Sun, 14 Mar 2010 19:49:44 +0000 (UTC) (envelope-from omerfsen@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id C383B8FC0A for ; Sun, 14 Mar 2010 19:49:43 +0000 (UTC) Received: by fxm1 with SMTP id 1so2057634fxm.13 for ; Sun, 14 Mar 2010 12:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=l7ZuYMK2vZ6RCUi5bUVcu2E3nXY30m7BanExabvr8xA=; b=d3Tl4D6D8+ejilYKstSO4SHo734YRLcwHqhufnQkMC2TdKaBpUTqgX/lWeDWEXrqqO thEjGWyRt+AMOWyfVtkjbVbEZIsAIJuHrng7CpaG5Caxe4GEfNUeGutpgOMZBfFCzwtP oUEIQFkDlHUFk7EC8Poomu645L2+eIegT/Zp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wJLreYKW8UUPHD6HD6w2TBTsieN6MuxifuzyEcD2977VEEtcxiNG/sr3G56ajWekfd rmhmhRIOhhV+rx0PFS/dImUpmHAao8JAx2yRIvoybjbUAzHEWU8LIZTHTJA4uVb44Z8/ izXvnZhkHQM0DZIw98fJtSyt/mcH55kRh6Ttk= MIME-Version: 1.0 Received: by 10.239.186.13 with SMTP id e13mr789968hbh.27.1268596182612; Sun, 14 Mar 2010 12:49:42 -0700 (PDT) Date: Sun, 14 Mar 2010 21:49:42 +0200 Message-ID: <75a268721003141249o477fdb6co80fe2cca7a94b695@mail.gmail.com> From: Omer Faruk Sen To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: gmultipath and netapp 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, 14 Mar 2010 19:49:44 -0000 Hi, Does anyone in this list use gmultipath with Netapp? I want to hear about your suggestions and experiences about that? Regards. From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 15 11:07:22 2010 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 ED6FA1065672 for ; Mon, 15 Mar 2010 11:07:21 +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 DB53D8FC23 for ; Mon, 15 Mar 2010 11:07:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2FB7LPx026990 for ; Mon, 15 Mar 2010 11:07:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2FB7LDe026988 for freebsd-scsi@FreeBSD.org; Mon, 15 Mar 2010 11:07:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Mar 2010 11:07:21 GMT Message-Id: <201003151107.o2FB7LDe026988@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, 15 Mar 2010 11:07:22 -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/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/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 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 p kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid 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/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping f kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll 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/119668 scsi [cam] [patch] certain errors are too verbose comparing 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/94838 scsi Kernel panic while mounting SD card with lock switch o 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/40895 scsi wierd kernel / device driver bug 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 37 problems total. From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 17 17:45:16 2010 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 3C9701065672 for ; Wed, 17 Mar 2010 17:45:16 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id EC6DB8FC21 for ; Wed, 17 Mar 2010 17:45:15 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id o2HHSmVr019554; Wed, 17 Mar 2010 11:28:48 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id o2HHSlG1019553; Wed, 17 Mar 2010 11:28:47 -0600 (MDT) (envelope-from ken) Date: Wed, 17 Mar 2010 11:28:47 -0600 From: "Kenneth D. Merry" To: Andriy Gapon Message-ID: <20100317172847.GA15531@nargothrond.kdm.org> References: <4B978175.3030805@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B978175.3030805@icyb.net.ua> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.92.1/10587/Tue Mar 16 18:14:33 2010 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs 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, 17 Mar 2010 17:45:16 -0000 On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote: > > At present pass(4) never retries a request (or performs any other kind of error > recovery) unless the request has CAM_PASS_ERR_RECOVER flag set. > This gives applications a control over error checking and handling. > But I think that in the case of CAM_REQUEUE_REQ status error recovery, > specifically a request retry, should always be performed. > > Rationale: > CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem. > It doesn't convey any information about state of medium, device, bus, controller > or the ccb itself. Application can not make any meaningful differentiation > based on this status. It either should always retry a ccb with this status or > face truly random failures. As such, I haven't encountered so far any > application that expects to get CAM_REQUEUE_REQ status. > So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be > leaked to applications unless retry count is exhausted (to prevent endless loops > in case of programming errors, primarily). > > What do you think? > Do you see any reason not to do it? Is there a particular case you're running into where CAM_REQUEUE_REQ is getting returned? I think it's better to keep the model as-is, to avoid confusion. Either the application is handling errors, and it can get any CAM status value, or it is asking the pass(4) driver to do error recovery and it doesn't have to handle things until error recovery is done and retries are exhausted. If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it shouldn't, we should probably look at that. Retries can get used up for various target-related reasons, like unit attention conditions, and we don't want to use CAM_REQUEUE_REQ when it isn't really needed. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 17 18:00:19 2010 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 644DD106566B for ; Wed, 17 Mar 2010 18:00:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AABE78FC13 for ; Wed, 17 Mar 2010 18:00:18 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA19651; Wed, 17 Mar 2010 20:00:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4BA118AD.6050102@icyb.net.ua> Date: Wed, 17 Mar 2010 20:00:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: "Kenneth D. Merry" References: <4B978175.3030805@icyb.net.ua> <20100317172847.GA15531@nargothrond.kdm.org> In-Reply-To: <20100317172847.GA15531@nargothrond.kdm.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs 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, 17 Mar 2010 18:00:19 -0000 on 17/03/2010 19:28 Kenneth D. Merry said the following: > On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote: >> At present pass(4) never retries a request (or performs any other kind of error >> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set. >> This gives applications a control over error checking and handling. >> But I think that in the case of CAM_REQUEUE_REQ status error recovery, >> specifically a request retry, should always be performed. >> >> Rationale: >> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem. >> It doesn't convey any information about state of medium, device, bus, controller >> or the ccb itself. Application can not make any meaningful differentiation >> based on this status. It either should always retry a ccb with this status or >> face truly random failures. As such, I haven't encountered so far any >> application that expects to get CAM_REQUEUE_REQ status. >> So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be >> leaked to applications unless retry count is exhausted (to prevent endless loops >> in case of programming errors, primarily). >> >> What do you think? >> Do you see any reason not to do it? > > Is there a particular case you're running into where CAM_REQUEUE_REQ is > getting returned? Yes, access to ATAPI devices with ahci(4). > I think it's better to keep the model as-is, to avoid confusion. Either > the application is handling errors, and it can get any CAM status value, or > it is asking the pass(4) driver to do error recovery and it doesn't have to > handle things until error recovery is done and retries are exhausted. I've had a chat with Justin Gibbs and he is of the same opinion. His explanation makes sense to me. I didn't look beyond 'for home use' applications when I came up with the suggestion. So, I think that we'd better teach affected applications about CAM_REQUEUE_REQ. > If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it > shouldn't, we should probably look at that. Retries can get used up for > various target-related reasons, like unit attention conditions, and we > don't want to use CAM_REQUEUE_REQ when it isn't really needed. I guess that this would be ideal. I think that it is an implementation detail in ahci(4) that some commands may get CAM_REQUEUE_REQ status. But I am not sure if there is an easy way to fix that given the general logic in that driver. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 18 08:59:46 2010 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 2C8B61065672 for ; Thu, 18 Mar 2010 08:59:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B7B248FC1E for ; Thu, 18 Mar 2010 08:59:45 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NsBZv-000PH9-MK for freebsd-scsi@freebsd.org; Thu, 18 Mar 2010 10:59:43 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Mar 2010 10:59:43 +0200 From: Daniel Braniss Message-ID: Subject: problems with mfi/DELL Perc6? 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: Thu, 18 Mar 2010 08:59:46 -0000 hi, we keep seeing these timeouts when there is heavy writes to the mfi: ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS the card is: mfi1: port 0xec00-0xecff mem 0xdf280000-0xdf2bffff,0xdf2c0000-0xd f2fffff irq 38 at device 0.0 on pci6 mfi1: Megaraid SAS driver Ver 3.00 any idea what the message means? thanks, danny From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 18 15:06:05 2010 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 1A7FF106564A for ; Thu, 18 Mar 2010 15:06:05 +0000 (UTC) (envelope-from Tom_Chard@Dell.com) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by mx1.freebsd.org (Postfix) with ESMTP id D5E148FC0C for ; Thu, 18 Mar 2010 15:06:04 +0000 (UTC) X-Loopcount0: from 10.166.72.159 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 09:55:37 -0500 Message-ID: <2F96965A484FC042AA2B4C174D18876B012F2BE4@ausx3mpc127.aus.amer.dell.com> In-Reply-To: <20100318120021.975DD1065717@hub.freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: freebsd-scsi Digest, Vol 360, Issue 2 Thread-Index: AcrGktv7nmzOKqeWRrWi8nlynq3PEwAGCZDw References: <20100318120021.975DD1065717@hub.freebsd.org> From: To: X-OriginalArrivalTime: 18 Mar 2010 14:55:38.0811 (UTC) FILETIME=[12A6D0B0:01CAC6AB] Subject: RE: freebsd-scsi Digest, Vol 360, Issue 2 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: Thu, 18 Mar 2010 15:06:05 -0000 Un fucking subscribe Unsubscribe Fucking unsubscribe -----Original Message----- From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd-scsi@freebsd.org] On Behalf Of freebsd-scsi-request@freebsd.org Sent: Thursday, March 18, 2010 5:00 AM To: freebsd-scsi@freebsd.org Subject: freebsd-scsi Digest, Vol 360, Issue 2 Send freebsd-scsi mailing list submissions to freebsd-scsi@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-scsi or, via email, send a message with subject or body 'help' to freebsd-scsi-request@freebsd.org You can reach the person managing the list at freebsd-scsi-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-scsi digest..." Today's Topics: 1. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Kenneth D. Merry) 2. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Andriy Gapon) 3. problems with mfi/DELL Perc6? (Daniel Braniss) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Mar 2010 11:28:47 -0600 From: "Kenneth D. Merry" Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs To: Andriy Gapon Cc: freebsd-scsi@freebsd.org Message-ID: <20100317172847.GA15531@nargothrond.kdm.org> Content-Type: text/plain; charset=3Dus-ascii On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote: >=20 > At present pass(4) never retries a request (or performs any other kind of error > recovery) unless the request has CAM_PASS_ERR_RECOVER flag set. > This gives applications a control over error checking and handling. > But I think that in the case of CAM_REQUEUE_REQ status error recovery, > specifically a request retry, should always be performed. >=20 > Rationale: > CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem. > It doesn't convey any information about state of medium, device, bus, controller > or the ccb itself. Application can not make any meaningful differentiation > based on this status. It either should always retry a ccb with this status or > face truly random failures. As such, I haven't encountered so far any > application that expects to get CAM_REQUEUE_REQ status. > So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be > leaked to applications unless retry count is exhausted (to prevent endless loops > in case of programming errors, primarily). >=20 > What do you think? > Do you see any reason not to do it? Is there a particular case you're running into where CAM_REQUEUE_REQ is getting returned? I think it's better to keep the model as-is, to avoid confusion. Either the application is handling errors, and it can get any CAM status value, or it is asking the pass(4) driver to do error recovery and it doesn't have to handle things until error recovery is done and retries are exhausted. If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it shouldn't, we should probably look at that. Retries can get used up for various target-related reasons, like unit attention conditions, and we don't want to use CAM_REQUEUE_REQ when it isn't really needed. Ken --=20 Kenneth Merry ken@kdm.org ------------------------------ Message: 2 Date: Wed, 17 Mar 2010 20:00:13 +0200 From: Andriy Gapon Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs To: "Kenneth D. Merry" Cc: freebsd-scsi@freebsd.org Message-ID: <4BA118AD.6050102@icyb.net.ua> Content-Type: text/plain; charset=3DISO-8859-1 on 17/03/2010 19:28 Kenneth D. Merry said the following: > On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote: >> At present pass(4) never retries a request (or performs any other kind of error >> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set. >> This gives applications a control over error checking and handling. >> But I think that in the case of CAM_REQUEUE_REQ status error recovery, >> specifically a request retry, should always be performed. >> >> Rationale: >> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem. >> It doesn't convey any information about state of medium, device, bus, controller >> or the ccb itself. Application can not make any meaningful differentiation >> based on this status. It either should always retry a ccb with this status or >> face truly random failures. As such, I haven't encountered so far any >> application that expects to get CAM_REQUEUE_REQ status. >> So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be >> leaked to applications unless retry count is exhausted (to prevent endless loops >> in case of programming errors, primarily). >> >> What do you think? >> Do you see any reason not to do it? >=20 > Is there a particular case you're running into where CAM_REQUEUE_REQ is > getting returned? Yes, access to ATAPI devices with ahci(4). > I think it's better to keep the model as-is, to avoid confusion. Either > the application is handling errors, and it can get any CAM status value, or > it is asking the pass(4) driver to do error recovery and it doesn't have to > handle things until error recovery is done and retries are exhausted. I've had a chat with Justin Gibbs and he is of the same opinion. His explanation makes sense to me. I didn't look beyond 'for home use' applications when I came up with the suggestion. So, I think that we'd better teach affected applications about CAM_REQUEUE_REQ. > If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it > shouldn't, we should probably look at that. Retries can get used up for > various target-related reasons, like unit attention conditions, and we > don't want to use CAM_REQUEUE_REQ when it isn't really needed. I guess that this would be ideal. I think that it is an implementation detail in ahci(4) that some commands may get CAM_REQUEUE_REQ status. But I am not sure if there is an easy way to fix that given the general logic in that driver. --=20 Andriy Gapon ------------------------------ Message: 3 Date: Thu, 18 Mar 2010 10:59:43 +0200 From: Daniel Braniss Subject: problems with mfi/DELL Perc6? To: freebsd-scsi@freebsd.org Message-ID: Content-Type: text/plain; charset=3Dus-ascii hi, we keep seeing these timeouts when there is heavy writes to the mfi: ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS the card is: mfi1: port 0xec00-0xecff mem 0xdf280000-0xdf2bffff,0xdf2c0000-0xd f2fffff irq 38 at device 0.0 on pci6 mfi1: Megaraid SAS driver Ver 3.00=20 any idea what the message means? thanks, danny ------------------------------ _______________________________________________ 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" End of freebsd-scsi Digest, Vol 360, Issue 2 ******************************************** From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 18 16:07:31 2010 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 4C847106564A for ; Thu, 18 Mar 2010 16:07:31 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 091E38FC0C for ; Thu, 18 Mar 2010 16:07:30 +0000 (UTC) Received: by gxk6 with SMTP id 6so1536055gxk.14 for ; Thu, 18 Mar 2010 09:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=WtO6bfDA8EvFvlLz97UNk1G/aaeJAqBWQZKyXumi3eo=; b=BZaTlWFVkwtwXcqkmy4UJwqRVo+o6FaW6miuKR1A2CK2hh1PYB2VN9WWJq4jQlngXf ig1FcE8kqgqbWwtj6eROnjTeRl5+7VEH7zPjSvi2Z6XoeiMEZBtQlxjDJnozFgmq4sMf mVIy1kYWGCumrZTsOO6bdxg+6fzJk8IpnpX8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=sNqu8VFCrr7UPj6Pto83fG567xFclQ/hUjHRoqosd1JPecJHypNOGLe6XuVYW4kl8w vzlU6mJyvCbGC8UuV89ZqbgdhFqy/yGZjTKdXJZ+/qqNvojCEMh6ghoTTCimfCQAOOUv SYnWhYzgXHSDoFkvytXCOTYGnAqx3C0PypdGk= Received: by 10.102.169.39 with SMTP id r39mr9213815mue.126.1268927101386; Thu, 18 Mar 2010 08:45:01 -0700 (PDT) Received: from orion.hsd1.pa.comcast.net (c-71-230-240-241.hsd1.pa.comcast.net [71.230.240.241]) by mx.google.com with ESMTPS id 12sm518232muq.31.2010.03.18.08.44.59 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 08:45:00 -0700 (PDT) Date: Thu, 18 Mar 2010 11:41:38 -0400 From: Glen Barber To: scsi@freebsd.org Message-ID: <20100318154138.GA30096@orion.hsd1.pa.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Optimum dev_openings value 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: Thu, 18 Mar 2010 16:07:31 -0000 Hi, I have three machines running 8.0-RELEASE, each with two mirrored Seagate SCSI disks using ZFS. In making sure these machines are performing as best as possible, I'm trying to find what the best practices are with regards to dev_openings values, and what determines the default dev_openings value. Two machines have identical ahc(4) Adaptec AIC7899 Ultra160 SCSI adapters, but display different defaults, which I have not had luck finding an explanation: h04# camcontrol tags da0 -v (pass0:ahc1:0:0:0): dev_openings 33 (pass0:ahc1:0:0:0): dev_active 0 (pass0:ahc1:0:0:0): devq_openings 33 (pass0:ahc1:0:0:0): devq_queued 0 (pass0:ahc1:0:0:0): held 0 (pass0:ahc1:0:0:0): mintags 2 (pass0:ahc1:0:0:0): maxtags 255 h21# camcontrol tags da0 -v (pass0:ahc0:0:0:0): dev_openings 64 (pass0:ahc0:0:0:0): dev_active 0 (pass0:ahc0:0:0:0): devq_openings 64 (pass0:ahc0:0:0:0): devq_queued 0 (pass0:ahc0:0:0:0): held 0 (pass0:ahc0:0:0:0): mintags 2 (pass0:ahc0:0:0:0): maxtags 255 h04# camcontrol devlist at scbus1 target 0 lun 0 (pass0,da0) at scbus1 target 1 lun 0 (pass1,da1) h21# camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) Is there an obvious explanation for the difference here? The third machine uses sym(4), which I expect would cause a different default dev_openings (currently defaulted to 44). Is there a general rule to adjusting this value? -- Glen Barber From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 18 17:06:01 2010 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 75044106566B for ; Thu, 18 Mar 2010 17:06:01 +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 2EF4B8FC1C for ; Thu, 18 Mar 2010 17:06:00 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o2IH605N036357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 18 Mar 2010 09:06:00 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4BA25D78.2090907@feral.com> Date: Thu, 18 Mar 2010 10:06:00 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc11 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <20100318154138.GA30096@orion.hsd1.pa.comcast.net> In-Reply-To: <20100318154138.GA30096@orion.hsd1.pa.comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Thu, 18 Mar 2010 09:06:00 -0800 (PST) Subject: Re: Optimum dev_openings value X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 17:06:01 -0000 Openings changes reflect when and how a device sends back a QUEUE FULL message, which causes FreeBSD to adjust the openings. That is disk, access pattern, and timing dependent. There are a number of theories about whether the 'openings' value should be bumped back up after having been throttled down. Nobody can agree on these theories, so the openings stay where they are. You might try manually adjusting them up on a periodic basis. > Hi, > > I have three machines running 8.0-RELEASE, each with two mirrored Seagate > SCSI disks using ZFS. In making sure these machines are performing as > best as possible, I'm trying to find what the best practices are with > regards to dev_openings values, and what determines the default > dev_openings value. > > Two machines have identical ahc(4) Adaptec AIC7899 Ultra160 SCSI adapters, > but display different defaults, which I have not had luck finding an > explanation: > > h04# camcontrol tags da0 -v > (pass0:ahc1:0:0:0): dev_openings 33 > (pass0:ahc1:0:0:0): dev_active 0 > (pass0:ahc1:0:0:0): devq_openings 33 > (pass0:ahc1:0:0:0): devq_queued 0 > (pass0:ahc1:0:0:0): held 0 > (pass0:ahc1:0:0:0): mintags 2 > (pass0:ahc1:0:0:0): maxtags 255 > > h21# camcontrol tags da0 -v > (pass0:ahc0:0:0:0): dev_openings 64 > (pass0:ahc0:0:0:0): dev_active 0 > (pass0:ahc0:0:0:0): devq_openings 64 > (pass0:ahc0:0:0:0): devq_queued 0 > (pass0:ahc0:0:0:0): held 0 > (pass0:ahc0:0:0:0): mintags 2 > (pass0:ahc0:0:0:0): maxtags 255 > > h04# camcontrol devlist > at scbus1 target 0 lun 0 (pass0,da0) > at scbus1 target 1 lun 0 (pass1,da1) > > h21# camcontrol devlist > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > > Is there an obvious explanation for the difference here? > > The third machine uses sym(4), which I expect would cause a different > default dev_openings (currently defaulted to 44). > > Is there a general rule to adjusting this value? > > From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 20 12:23:50 2010 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 85DE01065670; Sat, 20 Mar 2010 12:23:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9F58FC13; Sat, 20 Mar 2010 12:23:50 +0000 (UTC) Received: by iwn1 with SMTP id 1so772154iwn.27 for ; Sat, 20 Mar 2010 05:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=n4hsVIvu/CvOil0jxpzBDC28GfUAJXqAstPMmxrmVjI=; b=xlRLzIJRpznZENywl7ZUCGSiFQAi9Gky4WjnomJGTa3gjnCflYlu87X6jpX7m4I59u 0KFwrEaQAxLO32Ia7QvezuoqhGxLraq5LQHmAO3Ii/SzzTe6hqclaqeBbonWfj97/YcI BSZ5iT0F/1RSMRXb3ZolqvuiZamwjZDbpLNBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=J4VgO0fwI/CLQVa+wCdP5xt+Y3K+PdLPwAMsT+Ilncyve8FaX4gNwgL47ct1udpyjp +aA6GyBgWKp2PfC9Dyi4AtTvUjOL07NR8486KCwuW6vNSHXzKvBtvS1TeAlb1iOIDjyE rcBU2wKWjz/NQJfEZ4wtXnC+0iSCS5eL1GvEA= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.157.208 with SMTP id c16mr66998ibx.81.1269087829274; Sat, 20 Mar 2010 05:23:49 -0700 (PDT) In-Reply-To: <4B9A91DA.7030107@FreeBSD.org> References: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003031532u2207eb55h19c3a045215a7d84@mail.gmail.com> <4B8EF336.80107@feral.com> <3bbf2fe11003031547kd5f7314t3d83b2bde06c1c2f@mail.gmail.com> <4B8EF990.5030407@feral.com> <3bbf2fe11003031607wa3727b5ke89bc2a909d4d6a6@mail.gmail.com> <4B901419.8060800@feral.com> <3bbf2fe11003041737p30690522ya81e1b8f4bd6bbf9@mail.gmail.com> <3bbf2fe11003120601y3c403a1ct50f9fc6c1f0903bf@mail.gmail.com> <4B9A91DA.7030107@FreeBSD.org> Date: Sat, 20 Mar 2010 13:23:49 +0100 X-Google-Sender-Auth: 99783265dee31f85 Message-ID: <3bbf2fe11003200523t60895bfv1fa73d04e58a7838@mail.gmail.com> From: Attilio Rao To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-scsi@freebsd.org, "Justin T. Gibbs" , mj@feral.com, Ed Maste Subject: Re: How is supposed to be protected the units list? 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: Sat, 20 Mar 2010 12:23:50 -0000 2010/3/12 Alexander Motin : > Attilio Rao wrote: >> 2010/3/5 Attilio Rao : >>> 2010/3/4 Matthew Jacob : >>>> The referred to patch at least got me out of panic case :-).. >>>> >>>> http://people.freebsd.org/~mjacob/scsi_da.c.patch >>> Yes, honestly the main intent of this patch is to offer a stable >>> ground for correct handling of periph. When looking about refcounting >>> them correctly, the main problem is that there was no initial >>> condition assuring safety, and the initial patch should address this, >>> but I'm sure there are places where periph refcount is not handled >>> correctly and this may be one. >> >> So, as long as it seems nobody had a strong argument against this >> patch, what do you think about me committing it? >> We can further refine later if we think it is the case. >> >> Also, I think that Matt's patch should be committed just after this >> one (and possibly we should investigate a similar add-on for the ata >> counterpart too?). > > I have already told my opinion, that second lock may be not needed. I > would like to think a bit more about both patches after getting back > from the conference. Thanks, So I made this new patch using the bus lock: http://www.freebsd.org/~attilio/Sandvine/pdrv/xpt_lock.diff I would have preferred to have a dedicated lock for the units lists, but as long as you seem having strong opionion, I'm fine with it. Maybe Matt wants to add his refcounting modifies using this scheme if we came to a consensous? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein