From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 30 06:17:55 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 418C81A0 for ; Mon, 30 Mar 2015 06:17:55 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B98A591C for ; Mon, 30 Mar 2015 06:17:54 +0000 (UTC) Received: by wgbgs4 with SMTP id gs4so69506739wgb.0 for ; Sun, 29 Mar 2015 23:17:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=X7PlQw1TC4m18Yp6o2K5mqJHEz4fB09K9fcaEnVeOEs=; b=NnazsUbizzWjnG34rWKgcyYLfmI64mpQQM/4vAaMSh6yOPugcrncgif0V98/xD9A82 M68JEcU/hrQrvTInuuz/2EmdMabjiGGXSaCJ7ewo6uXKdGEXHvv/T8u51K0fo+DqSx7t VM/VHQXEnwS7MR2CSGH00pcX6aWz68cz8wolsh+YdXnhldIMcM5Djj5o0pgiLRmNXQP+ 3IWaIZbKEklpZMYhUO3DgYcWy2CBpqMC+T6ZqbU2kHfsObbfCtT/LoSWvBaf+5185INp UEcnLxtjiMn/0BzCN12voIWHfVn1QXwT+qMUpACG2kx9ZNum/+HdgsIA28OxBOCd9nj9 Twtw== X-Gm-Message-State: ALoCoQlug+f8/by+GPK3c5ajVhx1VTQHP4DUfbtmmAndKrUy849xn1hHEnApY81K2y2ZCeQlcjBo MIME-Version: 1.0 X-Received: by 10.181.11.202 with SMTP id ek10mr18400279wid.37.1427696266998; Sun, 29 Mar 2015 23:17:46 -0700 (PDT) Received: by 10.194.134.66 with HTTP; Sun, 29 Mar 2015 23:17:46 -0700 (PDT) Date: Mon, 30 Mar 2015 11:47:46 +0530 Message-ID: Subject: iscsictl/iscsicd:Capsicum capability mode not supported From: Aafak Mohammad To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 06:17:55 -0000 hi i am using freebsd 9.2 but i have back ported iscsictl and iscsid and native iscsi kernal from freebsd 10.1 to freebsd 9.2 Using iscsictl, i am able to discover and connect iSCSI target LUN on Ubunto 12.10 and able to perform dd on device nodes But as i execute zpool create command using these nodes getting following error in /var/log/messages Mar 27 17:15:09 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:10 trunk-mar26 iscsid[16845]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:10 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:11 trunk-mar26 iscsid[16846]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:11 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:12 trunk-mar26 iscsid[16850]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:12 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:13 trunk-mar26 iscsid[16851]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:13 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:14 trunk-mar26 iscsid[16852]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:14 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:15 trunk-mar26 iscsid[16855]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:15 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting Mar 27 17:15:16 trunk-mar26 iscsid[16857]: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not supported Mar 27 17:15:16 trunk-mar26 kernel: WARNING: 10.11.1.136 (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting I want to know, is it a merge issue or something i missed to set this mode. How can i activate this mode? --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 30 11:46:57 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7507CBD3 for ; Mon, 30 Mar 2015 11:46:57 +0000 (UTC) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC8B0241 for ; Mon, 30 Mar 2015 11:46:56 +0000 (UTC) Received: by wiaa2 with SMTP id a2so125574595wia.0 for ; Mon, 30 Mar 2015 04:46:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=NsCVf8LxDAsP+0hTOfshMEdYn0xm9W/bM4jID0ACbH8=; b=g6nj42IXtRL58qX1zie1YT0ksbZlY84rWm+TGCb8vAdF5Gj5QkiiOsQk6oskU3XwTi 54mKVNRyyK9UkrDy5A89TWovgtDuCPirsYfjI38eaWvrtXyU7bTwr0N1iWUCyZDTiiBt t/UL4+2pOfdYrSWnB+r1Xcw872q7eEuVl1EblP7T54UPTHd8LVKcCEXSW12DH0cgUz0a lfKoxNEDSOdpMaMiSuvJMCIbxr7tnmvB/9q+8K3rDUk5N0Ub5Yxlzd78HGqHklcid9NI pwGpegWhpC0mp6Vu/zlmIzgxGLG7qp9a4uWLMnku5QClX1//FY5V/nBt7YYHdmIgmniW TFng== X-Gm-Message-State: ALoCoQl+FsqY3FWkwvPI+iKw0ofgClmCfGUYRwK5coowRUGzlbdKVsy3g1to32e3/JoGST24EMuO MIME-Version: 1.0 X-Received: by 10.194.85.129 with SMTP id h1mr63671453wjz.147.1427716014899; Mon, 30 Mar 2015 04:46:54 -0700 (PDT) Received: by 10.194.134.66 with HTTP; Mon, 30 Mar 2015 04:46:54 -0700 (PDT) Date: Mon, 30 Mar 2015 17:16:54 +0530 Message-ID: Subject: Cannot connect iSCSI targets created on Nexent box From: Aafak Mohammad To: freebsd-scsi@freebsd.org, =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 11:46:57 -0000 Hi I am using freebsd 9.2 and back ported iscsictl/iscsid and native kenel iscsi changes from 10.1 to 9.2 I am able to discover and connect iSCSI targets on my Ubuntu box from freebsd 9.2 and able to create zpool on those iscsi targets Now i want to use nexenta targets LUNs for zpool creation so as i tried to connect it got the system into following state: root@trunk-mar26:~ # iscsictl Target name Target addr State iqn.2012-05.local.mynet:storage.sys1 10.11.1.136 Connected: da8 da9 da10 iqn.2012-05.local.mynet:storage.sys2 10.11.1.136 Connected: da11 da12 da13 *iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bfa 20.10.20.7 Connected: probe0 iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e 20.10.20.7 Connected: probe1 * As you can see first two iSCSI target(on Ubuntu) connected successfully and same device nodes i can see on camcontrol devlist but the last two saying connected but device nodes probe0, probe1 are not in camcontrol devlist */var/log/messages:* Mar 30 17:05:52 trunk-mar26 iscsid[28641]: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): Capsicum capability mode not supported Mar 30 17:05:52 trunk-mar26 iscsid[28640]: 20.10.20.7 *(iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bfa): received final login response without the "T" flagMar 30 17:05:52 trunk-mar26 iscsid[28641]: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): received final login response without the "T" flag* *root@trunk-mar26:~ # iscsictl -v* Session ID: 1 Initiator name: iqn.1994-09.org.freebsd:trunk-mar26 Initiator addr: Initiator alias: Target name: iqn.2012-05.local.mynet:storage.sys1 Target addr: 10.11.1.136 Target alias: User: Secret: Mutual user: Mutual secret: Session type: Normal Session state: Connected Failure reason: Header digest: None Data digest: None DataSegmentLen: 65536 ImmediateData: Yes iSER (RDMA): No Device nodes: da8 da9 da10 Session ID: 4 Initiator name: iqn.1994-09.org.freebsd:trunk-mar26 Initiator addr: Initiator alias: Target name: iqn.2012-05.local.mynet:storage.sys2 Target addr: 10.11.1.136 Target alias: User: Secret: Mutual user: Mutual secret: Session type: Normal Session state: Connected Failure reason: Header digest: None Data digest: None DataSegmentLen: 65536 ImmediateData: Yes iSER (RDMA): No Device nodes: da11 da12 da13 Session ID: 15 Initiator name: iqn.1994-09.org.freebsd:trunk-mar26 Initiator addr: Initiator alias: Target name: iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bf= a Target addr: 20.10.20.7 Target alias: User: Secret: Mutual user: Mutual secret: Session type: Normal *Session state: Connected* *Failure reason: * Header digest: None Data digest: None DataSegmentLen: 32768 ImmediateData: Yes iSER (RDMA): No *Device nodes: probe0 * Session ID: 16 Initiator name: iqn.1994-09.org.freebsd:trunk-mar26 Initiator addr: Initiator alias: Target name: iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096= e Target addr: 20.10.20.7 Target alias: User: Secret: Mutual user: Mutual secret: Session type: Normal *Session state: Connected* *Failure reason: * Header digest: None Data digest: None DataSegmentLen: 32768 ImmediateData: Yes iSER (RDMA): No *Device nodes: probe1 * --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 30 20:49:11 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B497F36B for ; Mon, 30 Mar 2015 20:49:11 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42F722F9 for ; Mon, 30 Mar 2015 20:49:11 +0000 (UTC) Received: by wgbdm7 with SMTP id dm7so82235720wgb.1 for ; Mon, 30 Mar 2015 13:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=axekvbnnWdrkmwVvlzML+nYwMmUWH9V58kV05cmlkV0=; b=uCZVR/60KuwUDeug3mHB9qH/PFYkJ/0E5RL+oJqS9SHtTslR+lG5eib3CmrC/ASjAF +Krr5jJOL3eevksjYFlIOpnHxPqFVnb4qm5oEETO1FPi9FYR8yKoUl4pjLJg1PwOXscB kFNrsa7E3NLFCX3XcIT6J0qr5bWuRFWoknt7DHANnp+IrUahiSUFdrC53lrDghk9q8h4 b8/tYTySCyQTjcGBvDrs+ZsftR+YpqDA5ArGS5Q55BwBJv/WCl5NHYFiPQsDUFYj5t4x WRUEeiM0PmySB2k9dmlIrDt26RsHwQuFrRkU0ZpraizKW35tWhpCmPwDe4tXBy6Nryda QmOA== X-Received: by 10.180.75.243 with SMTP id f19mr25872601wiw.94.1427748549240; Mon, 30 Mar 2015 13:49:09 -0700 (PDT) Received: from brick.home (abvb139.neoplus.adsl.tpnet.pl. [83.8.199.139]) by mx.google.com with ESMTPSA id ei8sm17912122wib.10.2015.03.30.13.49.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 13:49:07 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 30 Mar 2015 22:49:05 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Aafak Mohammad Subject: Re: Cannot connect iSCSI targets created on Nexent box Message-ID: <20150330204905.GA12290@brick.home> Mail-Followup-To: Aafak Mohammad , freebsd-scsi@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 20:49:11 -0000 On 0330T1716, Aafak Mohammad wrote: > Hi > I am using freebsd 9.2 and back ported iscsictl/iscsid and native kenel > iscsi changes from 10.1 to 9.2 > I am able to discover and connect iSCSI targets on my Ubuntu box from > freebsd 9.2 and able to create zpool on those iscsi targets > > Now i want to use nexenta targets LUNs for zpool creation > so as i tried to connect it got the system into following state: > > root@trunk-mar26:~ # iscsictl > Target name Target addr State > iqn.2012-05.local.mynet:storage.sys1 10.11.1.136 Connected: da8 da9 > da10 > iqn.2012-05.local.mynet:storage.sys2 10.11.1.136 Connected: da11 da12 > da13 > > *iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bfa > 20.10.20.7 Connected: probe0 > iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e > 20.10.20.7 Connected: probe1 * > > As you can see first two iSCSI target(on Ubuntu) connected successfully and > same device nodes i can see on camcontrol devlist > but the last two saying connected but device nodes probe0, probe1 are not > in camcontrol devlist > > */var/log/messages:* > > Mar 30 17:05:52 trunk-mar26 iscsid[28641]: 20.10.20.7 > (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): Capsicum > capability mode not supported > Mar 30 17:05:52 trunk-mar26 iscsid[28640]: 20.10.20.7 > *(iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bfa): received > final login response without the "T" flagMar 30 17:05:52 trunk-mar26 > iscsid[28641]: 20.10.20.7 > (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): received > final login response without the "T" flag* I think this is fixed by r271706. Can you update the code from 10.1-RELEASE to 10-STABLE and see if it works? Thanks! From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 30 20:50:50 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC2473BE for ; Mon, 30 Mar 2015 20:50:50 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF5730A for ; Mon, 30 Mar 2015 20:50:50 +0000 (UTC) Received: by wibg7 with SMTP id g7so515142wib.1 for ; Mon, 30 Mar 2015 13:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=RvpkKwWzB6Hyv1kTkbryuO4GAu1SJcT3FaXqruaRd4M=; b=q7FyAvo0LmG/MaDfD4k97RTuMNH9p5MeA5yEw+J5+0wOa/wIeqjoCAdcAeRBDLMbyc AhT50QtoHapUl4bSNqKdl4eV2mutJfZkoyfBvcFwUvh54kUhkPKReM3aKM5c3Zw1+eHi DJV/7ZkTM0lZ6u4RI71ClEvUxWIz7dkZYjfbKttCOD6PU6PYzSefaHa5hSRclKYenBI+ 6lZjEaVuVd03X/YbrWMLOzXlO3bCaoruUpOm2NwvBIJw1oW4FWnih/rdCywFCKHTKGAz l4y7F7hD0XuLK58rCqTWi5oeS6aiH8b9NgNvZxTSV3YeoCNLPGxdQjsahhJz1ifPgDQS SFSw== X-Received: by 10.194.208.229 with SMTP id mh5mr67493981wjc.108.1427748648690; Mon, 30 Mar 2015 13:50:48 -0700 (PDT) Received: from brick.home (abvb139.neoplus.adsl.tpnet.pl. [83.8.199.139]) by mx.google.com with ESMTPSA id ei8sm17917250wib.10.2015.03.30.13.50.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 13:50:47 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 30 Mar 2015 22:50:46 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Aafak Mohammad Subject: Re: iscsictl/iscsicd:Capsicum capability mode not supported Message-ID: <20150330205046.GB12290@brick.home> Mail-Followup-To: Aafak Mohammad , freebsd-scsi@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 20:50:50 -0000 On 0330T1147, Aafak Mohammad wrote: > hi > i am using freebsd 9.2 but i have back ported iscsictl and iscsid and > native iscsi kernal from freebsd 10.1 to freebsd 9.2 > Using iscsictl, i am able to discover and connect iSCSI target LUN on > Ubunto 12.10 and able to perform dd on device nodes But as i execute zpool > create command using these nodes getting following error in > /var/log/messages > > Mar 27 17:15:09 trunk-mar26 kernel: WARNING: 10.11.1.136 > (iqn.2012-05.local.mynet:storage.sys1): connection error; reconnecting > Mar 27 17:15:10 trunk-mar26 iscsid[16845]: 10.11.1.136 > (iqn.2012-05.local.mynet:storage.sys1): Capsicum capability mode not > supported [..] > I want to know, is it a merge issue or something i missed to set this mode. > How can i activate this mode? Required Capsicum features are not available in FreeBSD 9. You should be able to just #ifdef all the Capsicum-related parts; of course this way you lose the sandboxing. From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 30 22:24:08 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D9B284A; Mon, 30 Mar 2015 22:24:08 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 061DDFC; Mon, 30 Mar 2015 22:24:07 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t2UMNw17046520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 16:23:58 -0600 (MDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t2UMNwQi046519; Mon, 30 Mar 2015 16:23:58 -0600 (MDT) (envelope-from ken) Date: Mon, 30 Mar 2015 16:23:58 -0600 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: async pass(4) patches available Message-ID: <20150330222358.GA46342@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 30 Mar 2015 16:23:58 -0600 (MDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 22:24:08 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have put patches to add an asynchronous interface to the pass(4) driver and add a new camdd(8) utility here: FreeBSD/head as of SVN revision 280857: http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt FreeBSD stable/10 as of SVN revision 280856: http://people.freebsd.org/~ken/async_pass.stable_10.20150330.1.txt And the description / draft commit message: http://people.freebsd.org/~ken/async_pass_commitmsg.20150330.txt I have also attached the description and draft commit message to this email. The asynchronous changes to the pass(4) driver allow queueing and fetching CAM CCBs via two new ioctls. Notification of completed I/O can come via kqueue(2), poll(2), select(2), etc. The camdd(8) utility is intended as a simple data transfer utility, benchmark, and an in-tree example of how to use the asynchronous pass(4) interface. camdd(8) is still a work in progress. It needs to be cleaned up a bit and streamlined. There is one known arrival and departure bug with the pass(4) driver changes. We've reproduced it with our tests at Spectra, but I haven't yet tracked it down. There are many more arrival and departure bugs in FreeBSD/head, however. We have fixed quite a few in our local tree, but the test (called devad2) that triggers all of the problems uses the asynchronous pass(4) interface. So this is a prerequisite for fixing/verifying those bugs. Comments and testing are welcome! As I said, camdd(8) in particular is a work in progress. It could use some cleanup and there are some more useful features that could be added there. Part of the reason for camdd(8) was as a test facility for the new interface. But, it also serves as a useful demonstration of the asynchronous pass(4) functionality, given that the original application that used the API doesn't make sense to go into FreeBSD. (It is Spectra-specific, and not generally useful.) Ken -- Kenneth Merry ken@FreeBSD.ORG --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="async_pass_commitmsg.20150330.txt" Add asynchronous command support to the pass(4) driver, and the new camdd(8) utility. CCBs may be queued to the driver via the new CAMIOQUEUE ioctl, and completed CCBs may be retrieved via the CAMIOGET ioctl. User processes can use poll(2) or kevent(2) to get notification when I/O has completed. While the existing CAMIOCOMMAND blocking ioctl interface only supports user virtual data pointers in a CCB (generally only one per CCB), the new CAMIOQUEUE ioctl supports user virtual and physical address pointers, as well as user virtual and physical scatter/gather lists. This allows user applications to have more flexibility in their data handling operations. Kernel memory for data transferred via the queued interface is allocated from the zone allocator in MAXPHYS sized chunks, and user data is copied in and out. This is likely faster than the vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in configurations with many processors (there are more TLB shootdowns caused by the mapping/unmapping operation) but may not be as fast as running with unmapped I/O. The new memory handling model for user requests also allows applications to send CCBs with request sizes that are larger than MAXPHYS. The pass(4) driver now limits queued requests to the I/O size listed by the SIM driver in the maxio field in the Path Inquiry (XPT_PATH_INQ) CCB. There are some things things would be good to add: 1. Come up with a way to do unmapped I/O on multiple buffers. Currently the unmapped I/O interface operates on a struct bio, which includes only one address and length. It would be nice to be able to send an unmapped scatter/gather list down to busdma. This would allow eliminating the copy we currently do for data. 2. Add an ioctl to list currently outstanding CCBs in the various queues. 3. Add an ioctl to cancel a request, or use the XPT_ABORT CCB to do that. 4. Test physical address support. Virtual pointers and scatter gather lists have been tested, but I have not yet tested physical addresses or scatter/gather lists. 5. Investigate multiple queue support. At the moment there is one queue of commands per pass(4) device. If multiple processes open the device, they will submit I/O into the same queue and get events for the same completions. This is probably the right model for most applications, but it would be good to make sure that there is not really a case for multiple queues before pushing this code upstream. Also, add a new utility, camdd(8) that uses the asynchronous pass(4) driver interface. This utility is intended to be a basic data transfer/copy utility, a simple benchmark utility, and an example of how to use the asynchronous pass(4) interface. It can copy data to and from pass(4) devices using any target queue depth, starting offset and blocksize for the input and ouptut devices. It currently only supports SCSI devices, but could be easily extended to support ATA devices. It can also copy data to and from regular files, block devices, tape devices, pipes, stdin, and stdout. It does not support queueing multiple commands to any of those targets, since it uses the standard read(2)/write(2)/writev(2)/readv(2) system calls. The I/O is done by two threads, one for the reader and one for the writer. The reader thread sends completed read requests to the writer thread in strictly sequential order, even if they complete out of order. That could be modified later on for random I/O patterns or slightly out of order I/O. camdd(8) uses kqueue(2)/kevent(2) to get I/O compeltion events from the pass(4) driver and also to send request notifications internally. For pass(4) devcies, camdd(8) uses a single buffer (CAM_DATA_VADDR) per CAM CCB on the reading side, and a scatter/gather list (CAM_DATA_SG) on the writing side. In addition to testing both interfaces, this makes any potential reblocking of I/O easier. No data is copied between the reader and the writer, but rather the reader's buffers are split into multiple I/O requests or combined into a single I/O request depending on the input and output blocksize. For the file I/O path, camdd(8) also uses a single buffer (read(2), write(2), pread(2) or pwrite(2)) on reads, and a scatter/gather list (readv(2), writev(2), preadv(2), pwritev(2)) on writes. Things that would be nice to do for camdd(8) eventually: 1. Add support for I/O pattern generation. Patterns like all zeros, all ones, LBA-based patterns, random patterns, etc. Right Now you can always use /dev/zero, /dev/random, etc. 2. Add support for a "sink" mode, so we do only reads with no writes. Right now, you can use /dev/null. 3. Add support for automatic queue depth probing, so that we can figure out the right queue depth on the input and output side for maximum throughput. At the moment it defaults to 6. 4. Add support for SATA device passthrough I/O. 5. Add support for random LBAs and/or lengths on the input and side. 6. Track average per-I/O latency and busy time. The busy time and latency could also feed in to the automatic queue depth determination. sys/cam/scsi/scsi_pass.h: Define two new ioctls, CAMIOQUEUE and CAMIOGET, that queue and fetch asynchronous CAM CCBs respectively. Although these ioctls do not have a declared argument, they both take a union ccb pointer. If we declare a size here, the ioctl code in sys/kern/sys_generic.c will malloc and free a buffer for either the CCB or the CCB pointer (depending on how it is declared). Since we have to keep a copy of the CCB (which is fairly large) anyway, having the ioctl malloc and free a CCB for each call is wasteful. sys/cam/scsi/scsi_pass.c: Add asynchronous CCB support. Add two new ioctls, CAMIOQUEUE and CAMIOGET. CAMIOQUEUE adds a CCB to the incoming queue. The CCB is executed immediately (and moved to the active queue) if it is an immediate CCB, but otherwise it will be executed in passstart() when a CCB is available from the transport layer. When CCBs are completed (because they are immediate or passdone() if they are queued), they are put on the done queue. If we get the final close on the device before all pending I/O is complete, all active I/O is moved to the abandoned queue and we increment the peripheral reference count so that the peripheral driver instance doesn't go away before all pending I/O is done. The new passcreatezone() function is called on the first call to the CAMIOQUEUE ioctl on a given device to allocate the UMA zones for I/O requests and S/G list buffers. This may be good to move off to a taskqueue at some point. The new passmemsetup() function allocates memory and scatter/gather lists to hold the user's data, and copies in any data that needs to be written. For virtual pointers (CAM_DATA_VADDR), the kernel buffer is malloced from the new pass(4) driver malloc bucket. For virtual scatter/gather lists (CAM_DATA_SG), buffers are allocated from a new per-pass(9) UMA zone in MAXPHYS-sized chunks. Physical pointers are passed in unchanged. We have support for up to 16 scatter/gather segments (for the user and kernel S/G lists) in the default struct pass_io_req, so requests with longer S/G lists require an extra kernel malloc. The new passcopysglist() function copies a user scatter/gather list to a kernel scatter/gather list. The number of elements in each list may be different, but (obviously) the amount of data stored has to be identical. The new passmemdone() function copies data out for the CAM_DATA_VADDR and CAM_DATA_SG cases. The new passiocleanup() function restores data pointers in user CCBs and frees memory. Add new functions to support kqueue(2)/kevent(2): passreadfilt() tells kevent whether or not the done queue is empty. passkqfilter() adds a knote to our list. passreadfiltdetach() removes a knote from our list. Add a new function, passpoll(), for poll(2)/select(2) to use. Add devstat(9) support for the queued CCB path. usr.sbin/camdd/Makefile: Add a makefile for camdd(8). usr.sbin/camdd/camdd.8: Man page for camdd(8). usr.sbin/camdd/camdd.c: The new camdd(8) utility. --7AUc2qLy4jB3hD7Z-- From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 31 00:49:18 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26B8EF8E; Tue, 31 Mar 2015 00:49:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C6D32C5; Tue, 31 Mar 2015 00:49:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2V0nCZT086383 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Mar 2015 03:49:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2V0nCZT086383 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2V0nCtE086382; Tue, 31 Mar 2015 03:49:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Mar 2015 03:49:12 +0300 From: Konstantin Belousov To: "Kenneth D. Merry" Subject: Re: async pass(4) patches available Message-ID: <20150331004912.GM2379@kib.kiev.ua> References: <20150330222358.GA46342@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330222358.GA46342@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 00:49:18 -0000 On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > Kernel memory for data transferred via the queued interface is > allocated from the zone allocator in MAXPHYS sized chunks, and user > data is copied in and out. This is likely faster than the > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > configurations with many processors (there are more TLB shootdowns > caused by the mapping/unmapping operation) but may not be as fast > as running with unmapped I/O. cam_periph_mapmem() uses vmapbuf() with an indicator to always map the user pages mostly because I do not know CAM code and wanted to make the least intrusive changes there. It is not inherently impossible to pass unmapped pages down from cam_periph_mapmem(), but might require some more plumbing for driver to indicate that it is acceptable. > > The new memory handling model for user requests also allows > applications to send CCBs with request sizes that are larger than > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > size listed by the SIM driver in the maxio field in the Path > Inquiry (XPT_PATH_INQ) CCB. > > There are some things things would be good to add: > > 1. Come up with a way to do unmapped I/O on multiple buffers. > Currently the unmapped I/O interface operates on a struct bio, > which includes only one address and length. It would be nice > to be able to send an unmapped scatter/gather list down to > busdma. This would allow eliminating the copy we currently do > for data. Only because nothing more was needed. The struct bio does not use address/length pair when unmapped, it passes the list of physical pages, see bio_ma array pointer. It is indeed taylored to be a pointer to struct buf' b_pages, but it does not have to be. The busdma unmapped non-specific interface is bus_dmamap_load_ma(), which again takes array of pages to load. If you want some additional helper, suitable for your goals, please provide the desired interface definition. From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 31 22:51:00 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 561132A5; Tue, 31 Mar 2015 22:51:00 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 20E6A671; Tue, 31 Mar 2015 22:50:59 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t2VMopFx067670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 16:50:51 -0600 (MDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t2VMop3o067669; Tue, 31 Mar 2015 16:50:51 -0600 (MDT) (envelope-from ken) Date: Tue, 31 Mar 2015 16:50:51 -0600 From: "Kenneth D. Merry" To: Konstantin Belousov Subject: Re: async pass(4) patches available Message-ID: <20150331225051.GA64520@mithlond.kdm.org> References: <20150330222358.GA46342@mithlond.kdm.org> <20150331004912.GM2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150331004912.GM2379@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 31 Mar 2015 16:50:51 -0600 (MDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 22:51:00 -0000 On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote: > On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > > Kernel memory for data transferred via the queued interface is > > allocated from the zone allocator in MAXPHYS sized chunks, and user > > data is copied in and out. This is likely faster than the > > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > > configurations with many processors (there are more TLB shootdowns > > caused by the mapping/unmapping operation) but may not be as fast > > as running with unmapped I/O. > cam_periph_mapmem() uses vmapbuf() with an indicator to always map the > user pages mostly because I do not know CAM code and wanted to make > the least intrusive changes there. It is not inherently impossible > to pass unmapped pages down from cam_periph_mapmem(), but might > require some more plumbing for driver to indicate that it is acceptable. I think that would probably not be too difficult to change. That API isn't one that is exposed, so changing it shouldn't be a problem. The only reason not to do unmapped I/O there is just if the underlying controller doesn't support it. The lower parts of the stack shouldn't be trying to sniff the data that is read or written to the device, although that has happened in the past. We'd have to audit a couple of the drivers to make sure they aren't trying to access the data. > > The new memory handling model for user requests also allows > > applications to send CCBs with request sizes that are larger than > > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > > size listed by the SIM driver in the maxio field in the Path > > Inquiry (XPT_PATH_INQ) CCB. > > > > There are some things things would be good to add: > > > > 1. Come up with a way to do unmapped I/O on multiple buffers. > > Currently the unmapped I/O interface operates on a struct bio, > > which includes only one address and length. It would be nice > > to be able to send an unmapped scatter/gather list down to > > busdma. This would allow eliminating the copy we currently do > > for data. > Only because nothing more was needed. The struct bio does not use > address/length pair when unmapped, it passes the list of physical > pages, see bio_ma array pointer. It is indeed taylored to be a pointer > to struct buf' b_pages, but it does not have to be. > > The busdma unmapped non-specific interface is bus_dmamap_load_ma(), > which again takes array of pages to load. If you want some additional > helper, suitable for your goals, please provide the desired interface > definition. What I'd like to be able to do is pass down a CCB with a user virtual S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal with it. The trouble would likely be figuring out a flag to use to indicate that the S/G list in question contains user virtual pointers. (Backwards/binary compatibility is always an issue with CCB flags, since they have all been used.) But that is essentially what is needed. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 1 05:22:00 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F1361D5C for ; Wed, 1 Apr 2015 05:22:00 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98BA6DD2 for ; Wed, 1 Apr 2015 05:21:59 +0000 (UTC) Received: by wixm2 with SMTP id m2so27668173wix.0 for ; Tue, 31 Mar 2015 22:21:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Twvu7V1GMciHrNh6CuS76N4m44Wn4vTii9oD38nfXq0=; b=goeGkVtrfIuhFNGeZTzIhSH3bCLz8U+FXcCrszIdl8necv9U35ND0RFh9J/VUJnanm 7lozlHDmw2H4puUAteXhbUpGUiit2eIxGztZtLbU314gZKGkNfpd+PVbKut7EFlczeIs 7gMewiebWMD9NxXomzgOTR9jorujVYBbFWWqwcCLJ3X+NOma7dIr1DOzUvlsHymHRY6C msh3Hp5Z3TIOfss9/pA4GkQMKBEnAsjLW07GbaGZotbB4nM41pF6cF7E0pmCiUkyAAGp Z09F1oXi8kAX0/MY9xQU+jG5wQZUOAOU1AtpS40l5xK1J8r/CAUSOuPhmmUAk1hB/dp+ 3ikQ== X-Gm-Message-State: ALoCoQnn2ZzkV8qH2ZU96b0i68OmjWzUQ6pX2Pl5CNwF147QYKWvC//CdDJn967nvYXomi6m/RE7 MIME-Version: 1.0 X-Received: by 10.180.86.162 with SMTP id q2mr11516520wiz.26.1427865712469; Tue, 31 Mar 2015 22:21:52 -0700 (PDT) Received: by 10.194.134.66 with HTTP; Tue, 31 Mar 2015 22:21:52 -0700 (PDT) In-Reply-To: <20150330204905.GA12290@brick.home> References: <20150330204905.GA12290@brick.home> Date: Wed, 1 Apr 2015 10:51:52 +0530 Message-ID: Subject: Re: Cannot connect iSCSI targets created on Nexent box From: Aafak Mohammad To: freebsd-scsi@freebsd.org, =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:22:00 -0000 Thanks for helping, i merged the revision r271706 from stable 10 it works and i am able to connect Nexenta iSCSI targets Thanks a lot. On Tue, Mar 31, 2015 at 2:19 AM, Edward Tomasz Napiera=C5=82a wrote: > On 0330T1716, Aafak Mohammad wrote: > > Hi > > I am using freebsd 9.2 and back ported iscsictl/iscsid and native kenel > > iscsi changes from 10.1 to 9.2 > > I am able to discover and connect iSCSI targets on my Ubuntu box from > > freebsd 9.2 and able to create zpool on those iscsi targets > > > > Now i want to use nexenta targets LUNs for zpool creation > > so as i tried to connect it got the system into following state: > > > > root@trunk-mar26:~ # iscsictl > > Target name Target addr State > > iqn.2012-05.local.mynet:storage.sys1 10.11.1.136 Connected: da8 da= 9 > > da10 > > iqn.2012-05.local.mynet:storage.sys2 10.11.1.136 Connected: da11 > da12 > > da13 > > > > *iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bfa > > 20.10.20.7 Connected: probe0 > > iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e > > 20.10.20.7 Connected: probe1 * > > > > As you can see first two iSCSI target(on Ubuntu) connected successfully > and > > same device nodes i can see on camcontrol devlist > > but the last two saying connected but device nodes probe0, probe1 are n= ot > > in camcontrol devlist > > > > */var/log/messages:* > > > > Mar 30 17:05:52 trunk-mar26 iscsid[28641]: 20.10.20.7 > > (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): Capsicum > > capability mode not supported > > Mar 30 17:05:52 trunk-mar26 iscsid[28640]: 20.10.20.7 > > *(iqn.1986-03.com.sun:02:7957828f-1551-e04c-ed10-cce469c63bfa): receive= d > > final login response without the "T" flagMar 30 17:05:52 trunk-mar26 > > iscsid[28641]: 20.10.20.7 > > (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): received > > final login response without the "T" flag* > > I think this is fixed by r271706. Can you update the code from > 10.1-RELEASE > to 10-STABLE and see if it works? Thanks! > > --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 1 05:24:04 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAE631DC0 for ; Wed, 1 Apr 2015 05:24:04 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47AFAE05 for ; Wed, 1 Apr 2015 05:24:04 +0000 (UTC) Received: by wgbdm7 with SMTP id dm7so40925069wgb.1 for ; Tue, 31 Mar 2015 22:24:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Wcz3qGvA3OwcFE7RWd6nwkHutVp+YEPEZfxazTu/v+c=; b=GwPKLHNENbc+OX4zns86Iofo8LAHhpVS3cyopvCLs47qGCQ99GPBRpKOgdyZF+I3Rw KG9wCZkab3596h+d+Fq//497bj/QYWXdkpBwag0uof8zY6J45l/Jo7N61ebusvGr9FCm KAfS/bhla7nEo0O5QDqoF2daxLfGPQAzUwdlz+h5e/dsow7gbcrN9y4tLzaAPayBOgKv Nqd/qftczMPAEa1Is98zezsV7BK6V1e0cT55o8N534duRkCGjI6XpNw1Xm1sLLQgFpm7 xuoIVBO+Cw0AYseW4PY5+lYLNpSYypfI4qy3VlmtuaZvk8WYtw03BZ+AcNe2dAY4oFX6 SECg== X-Gm-Message-State: ALoCoQkl7cvMlwluxeN1bTdIfkKHSZE9Id0HCZGc0fSMi5iZRnHyA74MMQEXdq7x+hM8mC/DQTDK MIME-Version: 1.0 X-Received: by 10.194.157.39 with SMTP id wj7mr80389835wjb.57.1427865842383; Tue, 31 Mar 2015 22:24:02 -0700 (PDT) Received: by 10.194.134.66 with HTTP; Tue, 31 Mar 2015 22:24:02 -0700 (PDT) Date: Wed, 1 Apr 2015 10:54:02 +0530 Message-ID: Subject: Cannot create Pool on discovered iSCSI targets From: Aafak Mohammad To: freebsd-scsi@freebsd.org, =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:24:04 -0000 HI I have installed freebsd 10.1 and using iscsictl as initiator root@freebsd-10:~ # uname -a *FreeBSD freebsd-10.1 10.1-RC3* FreeBSD 10.1-RC3 #0 r273437: Tue Oct 21 23:55:15 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@freebsd-10:~ # Then i discovered iSCSI targate exist on Nexenta its connected and can see the devicenode in camcontrol devlist *root@freebsd-10:~ # iscsictl -A -d 20.10.20.7 * root@freebsd-10:~ # iscsictl Target name Target portal State iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e 20.10.20.7 Connected: da1 root@freebsd-10:~ # iscsictl -v Session ID: 2 Initiator name: iqn.1994-09.org.freebsd:freebsd-10.1 Initiator portal: Initiator alias: Target name: iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e Target portal: 20.10.20.7 Target alias: User: Secret: Mutual user: Mutual secret: Session type: Normal *Session state: Connected* Failure reason: Header digest: None Data digest: None DataSegmentLen: 32768 ImmediateData: Yes iSER (RDMA): No *Device nodes: da1 * *root@freebsd-10:~ # camcontrol devlist* at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (da0,pass1) * at scbus3 target 0 lun 0 (pass2,da1)* *root@freebsd-10:~ # zpool create pool1 /dev/da1* getting hung........... making it as a kernel thread *var/log/messages/* Apr 1 10:37:43 freebsd-10 kernel: WARNING: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): connection error; reconnecting Apr 1 10:37:46 freebsd-10 kernel: WARNING: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e):* connection error; reconnecting* Apr 1 10:37:47 freebsd-10 kernel: WARNING: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): connection error; reconnecting Apr 1 10:37:48 freebsd-10 kernel: WARNING: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): connection error; reconnecting Apr 1 10:37:49 freebsd-10 kernel: WARNING: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): connection error; reconnecting Apr 1 10:37:50 freebsd-10 kernel: WARNING: 20.10.20.7 (iqn.1986-03.com.sun:02:b3031b28-29d1-40d5-9f02-a95a428d096e): connection error; re root@freebsd-10:~ # ps -aux USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 100.0 0.0 0 16 - RL 10:19AM 24:01.68 [idle] root 0 0.0 0.2 0 2336 - DLs 10:19AM 0:06.83 [kernel] root 1 0.0 0.1 9472 840 - ILs 10:19AM 0:00.04 /sbin/init -- root 2 0.0 0.0 0 32 - DL 10:19AM 0:00.08 [cam] root 3 0.0 0.0 0 16 - DL 10:19AM 0:00.00 [mpt_recovery0] root 4 0.0 0.0 0 16 - DL 10:19AM 0:00.02 [fdc0] root 5 0.0 0.0 0 16 - DL 10:19AM 0:00.00 [sctp_iterator] root 6 0.0 0.0 0 16 - DL 10:19AM 0:00.03 [pagedaemon] root 7 0.0 0.0 0 16 - DL 10:19AM 0:00.00 [vmdaemon] root 8 0.0 0.0 0 16 - DL 10:19AM 0:00.00 [pagezero] root 9 0.0 0.0 0 32 - DL 10:19AM 0:00.04 [bufdaemon] root 10 0.0 0.0 0 16 - DL 10:19AM 0:00.00 [audit] root 12 0.0 0.0 0 240 - WL 10:19AM 0:03.01 [intr] root 13 0.0 0.0 0 48 - DL 10:19AM 0:00.04 [geom] root 14 0.0 0.0 0 16 - DL 10:19AM 0:00.26 [rand_harvestq] root 15 0.0 0.0 0 64 - DL 10:19AM 0:00.15 [usb] root 16 0.0 0.0 0 16 - DL 10:19AM 0:00.01 [vnlru] root 17 0.0 0.0 0 16 - DL 10:19AM 0:00.06 [syncer] root 136 0.0 0.1 12332 1684 - Is 10:19AM 0:00.00 adjkerntz -i root 315 0.0 0.1 14624 2132 - Is 10:19AM 0:00.00 dhclient: em0 [priv] (dhclient) _dhcp 351 0.0 0.1 14624 2244 - Is 10:19AM 0:00.01 dhclient: em0 (dhclient) root 366 0.0 0.3 13164 4528 - Is 10:19AM 0:00.00 /sbin/devd root 438 0.0 0.1 14492 2032 - Ss 10:19AM 0:00.29 /usr/sbin/syslogd -s root 557 0.0 0.2 21036 2968 - Ss 10:19AM 0:00.21 /usr/sbin/iscsid root 632 0.0 0.4 61204 6472 - Is 10:19AM 0:00.00 /usr/sbin/sshd root 635 0.0 0.4 24104 5312 - Ss 10:19AM 0:00.04 sendmail: accepting connections (sendmail) smmsp 638 0.0 0.3 24104 5076 - Is 10:19AM 0:00.00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) root 642 0.0 0.1 16592 2220 - Is 10:19AM 0:00.01 /usr/sbin/cron -= s root 701 0.0 0.5 86472 7064 - Is 10:23AM 0:00.15 sshd: root@pts/0 (sshd) root 707 0.0 0.5 86472 7104 - Ss 10:23AM 0:00.25 sshd: root@pts/1 (sshd) root 723 0.0 0.0 0 48 - DL 10:25AM 0:00.01 [zfskern] root 686 0.0 0.1 14488 1940 v0 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv0 root 687 0.0 0.1 14488 1940 v1 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv1 root 688 0.0 0.1 14488 1940 v2 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv2 root 689 0.0 0.1 14488 1940 v3 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv3 root 690 0.0 0.1 14488 1940 v4 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv4 root 691 0.0 0.1 14488 1940 v5 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv5 root 692 0.0 0.1 14488 1940 v6 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv6 root 693 0.0 0.1 14488 1940 v7 Is+ 10:19AM 0:00.00 /usr/libexec/getty Pc ttyv7 root 704 0.0 0.2 23572 3500 0 Is 10:23AM 0:00.06 -csh (csh) *root 722 0.0 0.2 40144 3284 0 D+ 10:25AM 0:01.19 zpool create ptest /dev/da1* root 710 0.0 0.2 23572 3500 1 Ss 10:23AM 0:00.03 -csh (csh) root 712 0.0 0.1 12336 1840 1 T 10:23AM 0:00.03 tail -f /var/log/messages root 1298 0.0 0.1 18736 2120 1 R+ 10:43AM 0:00.00 ps -aux root@freebsd-10:~ # After this i cannot do anything, can you please help me why this is happening in freebsd 10 ? --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 1 08:29:09 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA54A1B3; Wed, 1 Apr 2015 08:29:09 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31B0169B; Wed, 1 Apr 2015 08:29:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t318T48S042800 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 11:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t318T48S042800 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t318T3KP042799; Wed, 1 Apr 2015 11:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Apr 2015 11:29:03 +0300 From: Konstantin Belousov To: "Kenneth D. Merry" Subject: Re: async pass(4) patches available Message-ID: <20150401082903.GW2379@kib.kiev.ua> References: <20150330222358.GA46342@mithlond.kdm.org> <20150331004912.GM2379@kib.kiev.ua> <20150331225051.GA64520@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150331225051.GA64520@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 08:29:09 -0000 On Tue, Mar 31, 2015 at 04:50:51PM -0600, Kenneth D. Merry wrote: > On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote: > > On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > > > Kernel memory for data transferred via the queued interface is > > > allocated from the zone allocator in MAXPHYS sized chunks, and user > > > data is copied in and out. This is likely faster than the > > > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > > > configurations with many processors (there are more TLB shootdowns > > > caused by the mapping/unmapping operation) but may not be as fast > > > as running with unmapped I/O. > > cam_periph_mapmem() uses vmapbuf() with an indicator to always map the > > user pages mostly because I do not know CAM code and wanted to make > > the least intrusive changes there. It is not inherently impossible > > to pass unmapped pages down from cam_periph_mapmem(), but might > > require some more plumbing for driver to indicate that it is acceptable. > > I think that would probably not be too difficult to change. That API isn't > one that is exposed, so changing it shouldn't be a problem. The only > reason not to do unmapped I/O there is just if the underlying controller > doesn't support it. The lower parts of the stack shouldn't be trying to > sniff the data that is read or written to the device, although that has > happened in the past. We'd have to audit a couple of the drivers to > make sure they aren't trying to access the data. This is why I mentioned 'plumbing' required to map pages when needed. > > > > The new memory handling model for user requests also allows > > > applications to send CCBs with request sizes that are larger than > > > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > > > size listed by the SIM driver in the maxio field in the Path > > > Inquiry (XPT_PATH_INQ) CCB. > > > > > > There are some things things would be good to add: > > > > > > 1. Come up with a way to do unmapped I/O on multiple buffers. > > > Currently the unmapped I/O interface operates on a struct bio, > > > which includes only one address and length. It would be nice > > > to be able to send an unmapped scatter/gather list down to > > > busdma. This would allow eliminating the copy we currently do > > > for data. > > Only because nothing more was needed. The struct bio does not use > > address/length pair when unmapped, it passes the list of physical > > pages, see bio_ma array pointer. It is indeed taylored to be a pointer > > to struct buf' b_pages, but it does not have to be. > > > > The busdma unmapped non-specific interface is bus_dmamap_load_ma(), > > which again takes array of pages to load. If you want some additional > > helper, suitable for your goals, please provide the desired interface > > definition. > > What I'd like to be able to do is pass down a CCB with a user virtual > S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal > with it. Is there an existing definition of the 'user s/g list' ? Some structure, or existing example of use ? > > The trouble would likely be figuring out a flag to use to indicate that the > S/G list in question contains user virtual pointers. (Backwards/binary > compatibility is always an issue with CCB flags, since they have all been > used.) > > But that is essentially what is needed. > I can write the code, but I need API specification. Also, ideally I need a rough example which uses the API. From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 3 01:43:33 2015 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16AC248C for ; Fri, 3 Apr 2015 01:43:33 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1BA39BE for ; Fri, 3 Apr 2015 01:43:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t331hW6k000970 for ; Fri, 3 Apr 2015 01:43:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 199117] Kernel panic when iSCSI drops Date: Fri, 03 Apr 2015 01:43:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-scsi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 01:43:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199117 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-scsi@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-scsi@FreeBSD.ORG Sat Apr 4 09:54:10 2015 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D3ED1CC for ; Sat, 4 Apr 2015 09:54:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6391B150 for ; Sat, 4 Apr 2015 09:54:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t349sAAe008215 for ; Sat, 4 Apr 2015 09:54:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 199117] Kernel panic when iSCSI drops Date: Sat, 04 Apr 2015 09:54:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: trasz@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: trasz@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 09:54:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199117 Edward Tomasz Napierala changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-scsi@FreeBSD.org |trasz@FreeBSD.org Status|New |Open CC| |trasz@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-scsi@FreeBSD.ORG Sat Apr 4 13:57:29 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 224BB56C for ; Sat, 4 Apr 2015 13:57:29 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8924BC1B for ; Sat, 4 Apr 2015 13:57:28 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t34DvO7v084336 for ; Sat, 4 Apr 2015 15:57:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 49D4966A; Sat, 4 Apr 2015 15:57:24 +0200 (CEST) Message-ID: <551FEDBE.7020504@omnilan.de> Date: Sat, 04 Apr 2015 15:57:18 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: scsi@freebsd.org Subject: OT: Written DLT IV (and others) media for testing wanted X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8006D05A2285833108875D4" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 04 Apr 2015 15:57:24 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 13:57:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8006D05A2285833108875D4 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I'm looking for DLT IV tape cartridges _with data_. I could get a almost unused Sun StoreEdge SDLT-320, which should be able to read DLT IV Media, written in 4000/7000/8000,DLT1 and VS-80 drives. I'd like to see if it works and check for transfer speed (under FreeBSD).= Unfortunately I don't have any DLT drive which can write DLT IV tapes, just SuperDLT and VS1. So if you have old DLT IV media, containing data wich you would allow me to dump to /dev/null, I'd like to ask if you could ship them to germany. I will pay the shipping! Also for sending back if you don't want to get rid of the tapes. The tapes can/should be heavy used and sorted out of course! Please contact me directly (not subscirebed to scsi@) Thanks and have a nice easter weekend, -Harry P.S.: Same applies to SLR7Tape (ALRF-2), SLR32Tape (MLR-1), SLRtape24, SLR5Tape (QIC-4GB), SLR4[-DC] (QIC-2GB), VXA-1, DLT-VS160 --------------enigD8006D05A2285833108875D4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlUf7cMACgkQLDqVQ9VXb8hhxgCggQp5f4IdG+OMG+e4+5Wz7XyO k9cAoLKxIGMEXg74pafiLcYJnmVbVceI =HxjP -----END PGP SIGNATURE----- --------------enigD8006D05A2285833108875D4--