From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 8 11:07:06 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 06C431065670 for ; Mon, 8 Mar 2010 11:07:06 +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 DE4D78FC28 for ; Mon, 8 Mar 2010 11:07:05 +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 o28B75wc073810 for ; Mon, 8 Mar 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o28B75Pt073807 for freebsd-scsi@FreeBSD.org; Mon, 8 Mar 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Mar 2010 11:07:05 GMT Message-Id: <201003081107.o28B75Pt073807@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, 08 Mar 2010 11:07:06 -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/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/140091 scsi [da] [patch] allow for da(4) large block transfer than 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 Tue Mar 9 06:28:00 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 3511A106564A for ; Tue, 9 Mar 2010 06:28:00 +0000 (UTC) (envelope-from vikassoni85@gmail.com) Received: from mail-pz0-f199.google.com (mail-pz0-f199.google.com [209.85.222.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7E78FC17 for ; Tue, 9 Mar 2010 06:27:59 +0000 (UTC) Received: by pzk37 with SMTP id 37so4321412pzk.7 for ; Mon, 08 Mar 2010 22:27:59 -0800 (PST) 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=2DtYKTGHcgKmuFQR/rz/CWVlxTQYHOEj/dDo6coY8fs=; b=o67wwHY81yGDUSTUaLxhRFuw8p5mfUO3owXgalL15LCMkWqjLohleE+gjo0A92P0Pb g1U8UwejwFPY5l8YHcJT1HP8khNLMpWABzspmUHJ+7ynZQ4mWD5o54mAa2MZ8mDU87Ef G1cz0EEOCP3yVLhOenDsKI70Dp+iR0DOSBD+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h63C2Gh+LxRP9Zz4AUXGAuSZ8E+hFUHkKatGb8J4TfLzU4aFbyFhGEH8exh3CdZIe7 nXzAHao0/uHR7xuhpw9N7XbJ3m0txKlLivzcbMaezhRkCLGiuoS2hKphFlLbrOZtebBt ucv0MAsAc5U3tVzJtcoY0G09G6RzvBoGLBRYI= MIME-Version: 1.0 Received: by 10.114.16.8 with SMTP id 8mr4133071wap.102.1268114473451; Mon, 08 Mar 2010 22:01:13 -0800 (PST) Date: Tue, 9 Mar 2010 11:31:13 +0530 Message-ID: From: VIKAS SONI To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Query on mkpart behaviour when there is no SCSI connected. 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: Tue, 09 Mar 2010 06:28:00 -0000 Hi, We are debugging SCSI driver for LynxOS on ppc architecture board. We are trying to run mkpart application (mkpart /dev/rsdncr.0) on ppc board when there is no SCSI connected. The observed behavior is the user application will hang and (Ctrl + C) is used to get the bash prompt or to come out of user application. As the request for device identification is not completed due to no SCSI connected, it waits over semaphore at that point in the driver and does not return back to user application with some error. The only way to come out of user application is by pressing (Ctrl +C). >>>>>>>>>>>>>>>>>>>>>>>>>>>> [System: /] $ mkpart /dev/rsdncr.0 ^C [System: /] $ mkpart /dev/rsdncr.1 ^C [System: /] $ mkpart /dev/rsdncr.2 ^C [System: /] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is our understanding correct? Is the user application when no SCSI connected is supposed to behave in this way? Thanks in advance, Vikas Soni From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 10 11:35:25 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 8C33A106564A for ; Wed, 10 Mar 2010 11:35:25 +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 CDFB08FC13 for ; Wed, 10 Mar 2010 11:35:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA11978 for ; Wed, 10 Mar 2010 13:24:38 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NpK1l-0007pl-VG for freebsd-scsi@freebsd.org; Wed, 10 Mar 2010 13:24:38 +0200 Message-ID: <4B978175.3030805@icyb.net.ua> Date: Wed, 10 Mar 2010 13:24:37 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: 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, 10 Mar 2010 11:35:25 -0000 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? Here's a small patch that implements the behavior: --- a/sys/cam/scsi/scsi_pass.c +++ b/sys/cam/scsi/scsi_pass.c @@ -564,9 +564,8 @@ passsendccb * error recovery. */ cam_periph_runccb(ccb, - (ccb->ccb_h.flags & CAM_PASS_ERR_RECOVER) ? passerror : NULL, - /* cam_flags */ CAM_RETRY_SELTO, /* sense_flags */SF_RETRY_UA, - softc->device_stats); + passerror, /* cam_flags */ CAM_RETRY_SELTO, + /* sense_flags */SF_RETRY_UA, softc->device_stats); if (need_unmap != 0) cam_periph_unmapmem(ccb, &mapinfo); @@ -586,7 +585,10 @@ passerror periph = xpt_path_periph(ccb->ccb_h.path); softc = (struct pass_softc *)periph->softc; - - return(cam_periph_error(ccb, cam_flags, sense_flags, - &softc->saved_ccb)); + + if ((ccb->ccb_h.flags & CAM_PASS_ERR_RECOVER) != 0 || + (ccb->ccb_h.status & CAM_STATUS_MASK) == CAM_REQUEUE_REQ) + return(cam_periph_error(ccb, cam_flags, sense_flags, + &softc->saved_ccb)); + return(0); } I am not sure, perhaps I could just explicitly return ERESTART in the case of CAM_REQUEUE_REQ instead of going through cam_periph_error? -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 10 15:40:20 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 983DE106564A for ; Wed, 10 Mar 2010 15:40:20 +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 546E68FC1C for ; Wed, 10 Mar 2010 15:40:20 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o2AFeJsF075396 for ; Wed, 10 Mar 2010 07:40:19 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B97BD69.1040504@feral.com> Date: Wed, 10 Mar 2010 07:40:25 -0800 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4B978175.3030805@icyb.net.ua> In-Reply-To: <4B978175.3030805@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Wed, 10 Mar 2010 07:40:19 -0800 (PST) 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, 10 Mar 2010 15:40:20 -0000 I think it's a good idea, but returning ERESTART directly would be a more seamless change. > 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? > > Here's a small patch that implements the behavior: > --- a/sys/cam/scsi/scsi_pass.c > +++ b/sys/cam/scsi/scsi_pass.c > @@ -564,9 +564,8 @@ passsendccb > * error recovery. > */ > cam_periph_runccb(ccb, > - (ccb->ccb_h.flags& CAM_PASS_ERR_RECOVER) ? passerror : NULL, > - /* cam_flags */ CAM_RETRY_SELTO, /* sense_flags */SF_RETRY_UA, > - softc->device_stats); > + passerror, /* cam_flags */ CAM_RETRY_SELTO, > + /* sense_flags */SF_RETRY_UA, softc->device_stats); > > if (need_unmap != 0) > cam_periph_unmapmem(ccb,&mapinfo); > @@ -586,7 +585,10 @@ passerror > > periph = xpt_path_periph(ccb->ccb_h.path); > softc = (struct pass_softc *)periph->softc; > - > - return(cam_periph_error(ccb, cam_flags, sense_flags, > - &softc->saved_ccb)); > + > + if ((ccb->ccb_h.flags& CAM_PASS_ERR_RECOVER) != 0 || > + (ccb->ccb_h.status& CAM_STATUS_MASK) == CAM_REQUEUE_REQ) > + return(cam_periph_error(ccb, cam_flags, sense_flags, > + &softc->saved_ccb)); > + return(0); > } > > > I am not sure, perhaps I could just explicitly return ERESTART in the case of > CAM_REQUEUE_REQ instead of going through cam_periph_error? > > From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 11 17:15:32 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 37ECF1065670; Thu, 11 Mar 2010 17:15:32 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id D3DE38FC25; Thu, 11 Mar 2010 17:15:31 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id F055378C4B; Fri, 12 Mar 2010 02:15:30 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id B31C078C3B; Fri, 12 Mar 2010 02:15:30 +0900 (JST) Message-ID: <03429667FAB1490AB87F3CF16EE9228B@artemis> From: "Daisuke Aoyama" To: , Date: Fri, 12 Mar 2010 02:15:26 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01CAC189.E11C5090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: [PATCH] VirtualBox INT18 patch for gPXE iSCSI boot/install 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, 11 Mar 2010 17:15:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAC189.E11C5090 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit [PATCH] VirtualBox INT18 patch for gPXE iSCSI boot/install This patch provides next boot device when using gPXE. Before installing OS to an iSCSI target, you have to connect the target. And boot order must be gPXE first. It was tested only with iSCSI device. It comes to be able to construct the iSCSI boot environment easily by using gPXE(boot loader) and istgt(iSCSI target). See the link about using gPXE and istgt boot sample(FreeNAS): http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=102&t=5949 How to make: # cd /usr/ports/emulators/virtualbox-ose # tar xvf /path/to/vboxint18-20100310.tar.gz # make clean # make You can use it with my VNC patch. If you want both, use VNC patch method. I hope this helps iSCSI developing. Regards, Daisuke Aoyama ------=_NextPart_000_0007_01CAC189.E11C5090 Content-Type: application/octet-stream; name="vboxint18-20100310.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vboxint18-20100310.tar.gz" H4sICI53lksCA3Zib3hpbnQxOC0yMDEwMDMxMC50YXIA7VdLb9s4EM61+hUDFNhDrQf1smxnu5tn gRy2Ceoi6M2QJcqiK4sCSaVOf/0OKUeN8+weYmABD2DQ5Aw1H78Zcsgv58dn/5wfvKkQQoZRBLpF edgSkoQB+H4YxVESxj4B4gckCg6AHOxAWqlSgVAE5+olux8lpdXLi9xa3P9ErplQbVqd8DWEru8G cDk9h4vPX/0RNKnKSteyvpZMdh1oBL9hOZVQ07WCOVIGOb1hGQWkp4ZWsnoBi6tv5651QgsuKLAa +a0qPX45BcUhrYFNT6cXgLQvqLLhlrdQpjdUKzNe1zRToEq60bvWcZ13nrjIqYAVBgzm1HiBggmJ JtaUUjMH/XyHdM5bdQ8LusyBSbXYIJbpqqnoxCqVaiaeJ3krMg12Qd2aKi9tGuk1ZTOfe4WgtE6l d8PoD8Ublrk4/nfx0SfBH+pjPI7Gneu0khxKmuYVlRKuP592dPUuKvQuXf21ucxd9OQ1rKFilbLK 24w6dNVWqWK89gLiE+cTnYs2Fbcebo+IjN1SrSrLOm5VycXEOkuZbL9TOOa36SqFP1PTHjU0xYjV 1F02f1m/F/+CIWbvzfd/EsfP73/d2ex/EsaR3v/BMD6AeL//31y6+Jt0daTInGs8CZwzs6elc3Xq nFxcTh3BV3PGpZu9yfkfJmTYx9+PQiCBH8Tx/vzfhTiOAxh3T8fd28Tduzr1dNy9Pu54ZrHFu4CQ seMHjp9AEE6CZBIl7q8dPCBjQqzBYPAb33tnzjgSOrrak0k0nATxo08dHYEz9kliD2Fg2jCCoyML Dp2uQJXg6E4vFhYb5Y9mJZ73FRUTODyEE33gf8JztsVaJLAuYFGwBu9ZkdMCrk8uv1kD0HaCSqpg emXDdGrDGf7Op1qVVUw3K34DkK5teE/WRVHQfkw2No7r7pqLzqTrGm0ut7p0uyv7rlToZYMkzZe6 wgmqWlFjL0doUuuaVpYwb/rpc3Qtm37esl01uoSaytwV5TtTjYqsoyQwK0KzzUqQal8PLX8a5saz oM4fmwRbJqF4wiTcMolU2aOqOSJA6h+ganhjlrIVMGwrNcHo0DpnBXgfTIDgg2cBOsRLBMw6+yat WTZbyYVWlJXSDUPCNhkTjbqMSYb22CSM1iMWX25dWfTo/bh2bDxIDW1gqOtC9SQ0ExjUbqEcz4q2 znQ9N+jqTOfKBmA8skca4Ghs+11KAyiK6DrpkshARl/4D69fBJS4fXTr0hOX9c/NPKOZYR63Da55 eyV9fJ/jF50FdxetZ/kJdsPPMDH84CNgx/xgcr/AD2pf4SfcDT9JYvuxJiggdhDvkiDc2i8QhNpX CIremqD7f5/81qs0GQ/mnHmEddkTBY8PLo29kh2jz9g9uTzrHuuTO8ryyjbxqLqvIEJdnnLB8JmE T41Fq1fBJb5/9NNGWQd72cte9vKf5V8rlnB0ABQAAA== ------=_NextPart_000_0007_01CAC189.E11C5090-- From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 11 23:42:20 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B1CB1065673; Thu, 11 Mar 2010 23:42:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D58278FC0A; Thu, 11 Mar 2010 23:42:19 +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 o2BNgJVF050409; Thu, 11 Mar 2010 23:42:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2BNgJm2050405; Thu, 11 Mar 2010 23:42:19 GMT (envelope-from linimon) Date: Thu, 11 Mar 2010 23:42:19 GMT Message-Id: <201003112342.o2BNgJm2050405@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/144648: [aac] Strange values of speed and bus width in dmesg 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, 11 Mar 2010 23:42:20 -0000 Synopsis: [aac] Strange values of speed and bus width in dmesg Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 11 23:42:05 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144648 From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 12 06:07:01 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C00A1065675; Fri, 12 Mar 2010 06:07:01 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D90A28FC08; Fri, 12 Mar 2010 06:07:00 +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 o2C6700O078870; Fri, 12 Mar 2010 06:07:00 GMT (envelope-from mav@freefall.freebsd.org) Received: (from mav@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2C670de078866; Fri, 12 Mar 2010 06:07:00 GMT (envelope-from mav) Date: Fri, 12 Mar 2010 06:07:00 GMT Message-Id: <201003120607.o2C670de078866@freefall.freebsd.org> To: ai@kliksys.ru, mav@FreeBSD.org, freebsd-scsi@FreeBSD.org From: mav@FreeBSD.org Cc: Subject: Re: kern/140091: [da] [patch] allow for da(4) large block transfer than DFLTPHYS 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: Fri, 12 Mar 2010 06:07:01 -0000 Synopsis: [da] [patch] allow for da(4) large block transfer than DFLTPHYS State-Changed-From-To: open->closed State-Changed-By: mav State-Changed-When: Fri Mar 12 06:03:29 UTC 2010 State-Changed-Why: Support for larger I/O sizes were added to 8-STABLE. Not much controller drivers now announce such capability, but it is different question. http://www.freebsd.org/cgi/query-pr.cgi?pr=140091 From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 12 14:01:56 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 71A701065670; Fri, 12 Mar 2010 14:01:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1757F8FC26; Fri, 12 Mar 2010 14:01:55 +0000 (UTC) Received: by iwn15 with SMTP id 15so1063294iwn.7 for ; Fri, 12 Mar 2010 06:01:55 -0800 (PST) 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=3PupD9xAVI1R+Pi8o6F51wfQ8usucqwAYNpYBBi4XWY=; b=WMwDNv3O/j+24RBlSfEjDK0GbUKb/eptabne8dY+Zyq+EMsr+U78uXjE0kANMu6UjR ImeczUzTB5HQZ+Mkluj1WPCUwgQRPOpPyERQqnc/6LZW2sLn1kqjajwPTpHrRtgJ+oZn 9iydMJVN3F1cqAgr4ONwzs135Q3jPk9VDdbAY= 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=Fv/l/bdSAGJYUDqOVeZcauHOCmz+4S2ngoCQbw1fFcDSxg4PTzMWRloWiR+Mczn/Z3 5MLUQs9Ns3TXcGElGV0kT5GAvB3NOJjYf2tNloZj1ImOUCJdIaVULieU/GaFlFp4N6NM AS3BXlHiQZQ6Qlr4h9ZKDKsOjNLJlLS/jtF0k= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.191.147 with SMTP id dm19mr41534ibb.86.1268402514865; Fri, 12 Mar 2010 06:01:54 -0800 (PST) In-Reply-To: <3bbf2fe11003041737p30690522ya81e1b8f4bd6bbf9@mail.gmail.com> References: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003031357o518d6028m8157d9110a9122f3@mail.gmail.com> <4B8EF128.8050704@feral.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> Date: Fri, 12 Mar 2010 15:01:54 +0100 X-Google-Sender-Auth: df21b1c7ede34370 Message-ID: <3bbf2fe11003120601y3c403a1ct50f9fc6c1f0903bf@mail.gmail.com> From: Attilio Rao To: mj@feral.com, Alexander Motin , "Justin T. Gibbs" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-scsi@freebsd.org 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: Fri, 12 Mar 2010 14:01:56 -0000 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?). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 12 14:51:40 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 61A39106564A for ; Fri, 12 Mar 2010 14:51:40 +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 34B298FC16 for ; Fri, 12 Mar 2010 14:51:39 +0000 (UTC) Received: from [172.16.135.102] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o2CEpd1f009632 for ; Fri, 12 Mar 2010 06:51:39 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B9A54F6.8040204@feral.com> Date: Fri, 12 Mar 2010 06:51:34 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003031357o518d6028m8157d9110a9122f3@mail.gmail.com> <4B8EF128.8050704@feral.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> In-Reply-To: <3bbf2fe11003120601y3c403a1ct50f9fc6c1f0903bf@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Fri, 12 Mar 2010 06:51:39 -0800 (PST) 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: Fri, 12 Mar 2010 14:51:40 -0000 I'm okay with it at present. > 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?). > > Thanks, > Attilio > > > From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 12 19:11:40 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 7E656106568A; Fri, 12 Mar 2010 19:11:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id AABB08FC18; Fri, 12 Mar 2010 19:11:39 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so459893fga.13 for ; Fri, 12 Mar 2010 11:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3ZZdbbVAwmDEQNgzfBUI4vJnQ46YY2bwViS9tT72wvU=; b=TRKVxvTI7juKQ3fhadwGQVtYpWMp4NwL4ZhWnWrSSFkrhJ6PoCJvkvFU/rjrrOA8zs ETxvsZCVyrMkmbmN4FfGJ9G0apoRZJCpcaG5bsw5a3rSJxfmt03h7CA3eCN6XVd5/MSi zqIrZyBh0HTPbQ4Z65nFCsVjVMkRBSYcAotPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=J5wHwARQ9PC53C2gCJqxWyrLOe1aktsxe2dKSmQs/YF0v/uS0ISaQCH2AOkDDHRxYT qp5XMRAbOvogEswQ63NggRrt6u1KmoLkg51jmn91XsJuXUUoSNhPy+TvY/lSjx7vbVw1 WpQ1yHQNud/B8FDnFbw8DF+sB+ryqo2ZV5iUM= Received: by 10.87.66.14 with SMTP id t14mr4211950fgk.60.1268421098371; Fri, 12 Mar 2010 11:11:38 -0800 (PST) Received: from mavbook.mavhome.dp.ua (s224.GtokyoFL6.vectant.ne.jp [222.228.90.224]) by mx.google.com with ESMTPS id 14sm1230553fxm.13.2010.03.12.11.11.35 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Mar 2010 11:11:37 -0800 (PST) Sender: Alexander Motin Message-ID: <4B9A91DA.7030107@FreeBSD.org> Date: Fri, 12 Mar 2010 21:11:22 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Attilio Rao References: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003031357o518d6028m8157d9110a9122f3@mail.gmail.com> <4B8EF128.8050704@feral.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> In-Reply-To: <3bbf2fe11003120601y3c403a1ct50f9fc6c1f0903bf@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Justin T. Gibbs" , mj@feral.com 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: Fri, 12 Mar 2010 19:11:40 -0000 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, -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 12 19:19:33 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 A4E1A1065708 for ; Fri, 12 Mar 2010 19:19:33 +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 7A2FF8FC1A for ; Fri, 12 Mar 2010 19:19:33 +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 o2CJJB5d012150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 12 Mar 2010 11:19:32 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B9A93AC.9020000@feral.com> Date: Fri, 12 Mar 2010 11:19:08 -0800 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: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003031357o518d6028m8157d9110a9122f3@mail.gmail.com> <4B8EF128.8050704@feral.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> In-Reply-To: <4B9A91DA.7030107@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; 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]); Fri, 12 Mar 2010 11:19:33 -0800 (PST) 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 Reply-To: mj@feral.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:19:33 -0000 That's a fair comment. There is at least one case where this additional lock has helped. It probably needs rethinking a little later, but for now it does seem to help people. > 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, > > From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 12 19:29:14 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 15540106567B; Fri, 12 Mar 2010 19:29:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f185.google.com (mail-iw0-f185.google.com [209.85.223.185]) by mx1.freebsd.org (Postfix) with ESMTP id A7D8C8FC13; Fri, 12 Mar 2010 19:29:13 +0000 (UTC) Received: by iwn15 with SMTP id 15so1405307iwn.7 for ; Fri, 12 Mar 2010 11:29:13 -0800 (PST) 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=eFDz4PuRxEQAwuDe/IIJ6XvkD7R/Pb9yPUDMgIhefuI=; b=xNTEDhyb+g4I/JoEHXrWhqB1tTIWc8DYxL9xC1QO1uiRTw9Gpb0N538Wldjh3OVJDp 0YScPHZXLBtl71lVKul/JAtB0spn0ib7ftcIqbcXt4mmBHp2X3++ipNMGHCQYozWuuBT RcOj9+A4NgE5brJei1ZmZjGRTVi13X/S65MaE= 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=j0pQatsRYje3RZR4TPu3buBAG09o4sF4p9qExgjgf9IF66zsiU56UXTcP6T+aThFkc quG816SXP6re5oBYcq24dQAnkA6Mp3RaIex/O1SB2Ty776Y0xiC+L9rU7G81b0+7z9xB oHUERtR/z8dvDuEC3/N4hAZZ66oR7AT4FOYGc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.79.136 with SMTP id p8mr106852ibk.4.1268422152596; Fri, 12 Mar 2010 11:29:12 -0800 (PST) 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: Fri, 12 Mar 2010 20:29:12 +0100 X-Google-Sender-Auth: 2992d9f31c1dbf02 Message-ID: <3bbf2fe11003121129w69b6e48xfc3982bd9016bcce@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 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: Fri, 12 Mar 2010 19:29:14 -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, If you don't want to use the second lock, you have to use xpt_lock in all the other places anyways. I think it can get messy in particular if linked to another aspect: Another question, may be to integrate that locking paradigm directly with reference count of periph. It depends by if the periph can came from other parts as well. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 13 00:41: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 CFA7C106566B for ; Sat, 13 Mar 2010 00:41:50 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail2.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 95D628FC0C for ; Sat, 13 Mar 2010 00:41:50 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mail2.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 19:41:49 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id AF92411712; Fri, 12 Mar 2010 19:41:49 -0500 (EST) Date: Fri, 12 Mar 2010 19:41:49 -0500 From: Ed Maste Cc: freebsd-scsi@freebsd.org Message-ID: <20100313004149.GA94041@sandvine.com> References: <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> <4B9A93AC.9020000@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9A93AC.9020000@feral.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 13 Mar 2010 00:41:49.0456 (UTC) FILETIME=[F782D900:01CAC245] 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, 13 Mar 2010 00:41:50 -0000 On Fri, Mar 12, 2010 at 11:19:08AM -0800, Matthew Jacob wrote: > That's a fair comment. There is at least one case where this additional > lock has helped. It probably needs rethinking a little later, but for > now it does seem to help people. Right, the change is an improvement over the status quo; we were experiencing an easily reproducible panic from this issue that is solved by this change. We can always change it again if a more optimal soultion is proposed. Thanks, Ed