From owner-freebsd-scsi@FreeBSD.ORG Sun May 16 17:27: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 A4F101065676 for ; Sun, 16 May 2010 17:27:25 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 640E98FC08 for ; Sun, 16 May 2010 17:27:25 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o4GHRK07057559; Sun, 16 May 2010 11:27:20 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BEDF5BD.9040502@feral.com> Date: Sun, 16 May 2010 11:27:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BEDF5BD.9040502@feral.com> To: Matthew Jacob X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: addition of an XPT_SCAN_TGT code X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 17:27:25 -0000 I had something similar in mind. Glad you got there first, looks = reasonable. Scott On May 14, 2010, at 7:15 PM, Matthew Jacob wrote: > Sometimes, particularly in relation to a hotplug event, you just want = to scan a target id, not the whole bus. It's lighter weight. >=20 > The attached patch adds this with a relatively light touch. I'm not = super happy with it, but it does make rescanning on a target basis = doable. >=20 > Comments? >=20 > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to = "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Sun May 16 22:13:54 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 535091065674 for ; Sun, 16 May 2010 22:13:54 +0000 (UTC) (envelope-from devel@morey-chaisemartin.com) Received: from 31.mail-out.ovh.net (31.mail-out.ovh.net [213.186.62.10]) by mx1.freebsd.org (Postfix) with SMTP id B8F1A8FC12 for ; Sun, 16 May 2010 22:13:53 +0000 (UTC) Received: (qmail 14065 invoked by uid 503); 16 May 2010 21:51:24 -0000 Received: from b7.ovh.net (HELO mail172.ha.ovh.net) (213.186.33.57) by 31.mail-out.ovh.net with SMTP; 16 May 2010 21:51:24 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 16 May 2010 21:47:11 -0000 Received: from mut38-4-82-233-116-185.fbx.proxad.net (HELO ?10.0.2.12?) (devel@morey-chaisemartin.com@82.233.116.185) by ns0.ovh.net with SMTP; 16 May 2010 21:47:10 -0000 Message-ID: <4BF067DC.4030402@morey-chaisemartin.com> Date: Sun, 16 May 2010 23:47:08 +0200 From: Nicolas Morey-Chaisemartin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 7484419631062240940 X-Ovh-Remote: 82.233.116.185 (mut38-4-82-233-116-185.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.500002/N Subject: Read performance problem with iSCSI X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: devel@morey-chaisemartin.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 22:13:54 -0000 Hi, I am not sure if this is the right place, some my apologies if I'm mistaken. I have a FreeBSD 8.0 stable running on an amd64 machine (with the last 2.2.4 iscsi tarball from http://www.cs.huji.ac.il/~danny/ftp/freebsd/). It is connected to a Thecus N5500 pro using iSCSI. I've configured using the tutorial all over Google and it works ! Using dd, I get 52MB/s write speed which is a bit lower than expected but still allright. However reading is deadly slow. At best, I reached something like 8MB/s which is unacceptable. After looking through Google and old mailing list mails, I made sure I have enough tags but increasing the value did not really help. All the other tips i could find were about fine tuning and nothing to gain a factor of 6 or 7... Has any one see this problem or can someone point me in a direction to look for? One weird thing I noticed while playing with camcontrol is I get an error on access rate. Sun# camcontrol inquiry da0 pass0: Fixed Direct Access SCSI-4 device pass0: Serial Number camcontrol: error getting transfer settings Thanks in advance Nicolas Here's my config (feel free to ask for more info): Sun# cat /etc/iscsi.conf stephano { authmethod = None TargetName = iqn.2010-5.com.****:RAID.iscsi0.vg0.store TargetAddress = 10.0.2.55:3260,1 tags = 64 } Sun# sysctl net.iscsi_initiator net.iscsi_initiator.driver_version: 2.2.4 net.iscsi_initiator.isid: €DIB00 net.iscsi_initiator.sessions: 1 net.iscsi_initiator.0.targetname: iqn.2010-5.com****:RAID.iscsi0.vg0.store net.iscsi_initiator.0.targeaddress: 10.0.2.55 net.iscsi_initiator.0.stats: recv=46460 sent=46460 flags=0x0000039f pdus-alloc=0 pdus-max=5 cws=33 cmd=b57b exp=b57b max=b59b stat=b57b itt=b57b net.iscsi_initiator.0.douio: 0 net.iscsi_initiator.0.pid: 1608 From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 03:07:24 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 BC8801065672 for ; Mon, 17 May 2010 03:07:24 +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 839AA8FC0A for ; Mon, 17 May 2010 03:07:24 +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 o4H37NFB068805 for ; Sun, 16 May 2010 20:07:24 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF0B2F3.8030002@feral.com> Date: Sun, 16 May 2010 20:07:31 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BEDF5BD.9040502@feral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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]); Sun, 16 May 2010 20:07:24 -0700 (PDT) Subject: Re: addition of an XPT_SCAN_TGT code 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, 17 May 2010 03:07:24 -0000 On 5/16/2010 10:27 AM, Scott Long wrote: > I had something similar in mind. Glad you got there first, looks reasonable. > > Thanks. Anyone else have comments? From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 03:20:41 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 631FA106564A for ; Mon, 17 May 2010 03:20:41 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 111248FC22 for ; Mon, 17 May 2010 03:20:40 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id o4H3Kc7R034717; Sun, 16 May 2010 21:20:38 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id o4H3KcqC034716; Sun, 16 May 2010 21:20:38 -0600 (MDT) (envelope-from ken) Date: Sun, 16 May 2010 21:20:37 -0600 From: "Kenneth D. Merry" To: Matthew Jacob Message-ID: <20100517032037.GA34571@nargothrond.kdm.org> References: <4BEDF5BD.9040502@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEDF5BD.9040502@feral.com> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org Subject: Re: addition of an XPT_SCAN_TGT code 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, 17 May 2010 03:20:41 -0000 On Fri, May 14, 2010 at 18:15:41 -0700, Matthew Jacob wrote: > Sometimes, particularly in relation to a hotplug event, you just want to > scan a target id, not the whole bus. It's lighter weight. > > The attached patch adds this with a relatively light touch. I'm not > super happy with it, but it does make rescanning on a target basis doable. > > Comments? Looks good, good idea! Just two comments: > diff -r 85c0fa25a2fc sys/cam/cam_ccb.h > --- a/sys/cam/cam_ccb.h Fri May 14 15:55:34 2010 -0700 > +++ b/sys/cam/cam_ccb.h Fri May 14 18:14:46 2010 -0700 > @@ -207,6 +207,10 @@ > /* Notify Host Target driver of event */ > XPT_NOTIFY_ACKNOWLEDGE = 0x37 | XPT_FC_QUEUED | XPT_FC_USER_CCB, > /* Acknowledgement of event */ > +/* overflow commands: 0x40 ->0x4F */ > + XPT_SCAN_TGT = 0x40 | XPT_FC_QUEUED | XPT_FC_USER_CCB > + | XPT_FC_XPT_ONLY, > + /* (Re)Scan the SCSI Bus */ > Perhaps this would be better put at 0x1e? XPT_SCAN_LUN is in the same group, and this is similar. > diff -r 85c0fa25a2fc sys/dev/isp/isp_freebsd.c > --- a/sys/dev/isp/isp_freebsd.c Fri May 14 15:55:34 2010 -0700 > +++ b/sys/dev/isp/isp_freebsd.c Fri May 14 18:14:46 2010 -0700 > @@ -3898,7 +3898,7 @@ > * Scan the whole bus instead of target, which will then > * force a scan of all luns. > */ > - if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, cam_sim_path(fc->sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { > + if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, cam_sim_path(fc->sim), tgt, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { > isp_prt(isp, ISP_LOGWARN, "unable to create path for rescan"); > xpt_free_ccb(ccb); > return; The comment above should probably be updated. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 06:42: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 323CF1065670 for ; Mon, 17 May 2010 06:42:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id DE72C8FC1A for ; Mon, 17 May 2010 06:42:13 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1ODu1j-000Kke-Oe; Mon, 17 May 2010 09:42:11 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: devel@morey-chaisemartin.com In-reply-to: <4BF067DC.4030402@morey-chaisemartin.com> References: <4BF067DC.4030402@morey-chaisemartin.com> Comments: In-reply-to Nicolas Morey-Chaisemartin message dated "Sun, 16 May 2010 23:47:08 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2010 09:42:11 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-scsi@freebsd.org Subject: Re: Read performance problem with iSCSI 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, 17 May 2010 06:42:14 -0000 > Hi, >=20 > I am not sure if this is the right place, some my apologies if I'm mist= ak=3Den. > I have a FreeBSD 8.0 stable running on an amd64 machine (with the last = 2.=3D2.4 iscsi tarball from http://www.cs.huji.ac.il/=7Edanny/ftp/freebsd= /).=20 > It is connected to a Thecus N5500 pro using iSCSI. >=20 > I've configured using the tutorial all over Google and it works =21 > Using dd, I get 52MB/s write speed which is a bit lower than expected b= ut=3D still allright. However reading is deadly slow.> At best, I reached= something like 8MB/s which is unacceptable. >=20 > After looking through Google and old mailing list mails, I made sure I = ha=3Dve enough tags but increasing the value did not really help.> All th= e other tips i could find were about fine tuning and nothing to gai=3Dn a= factor of 6 or 7... >=20 > Has any one see this problem or can someone point me in a direction to = lo=3Dok for? >=20 > One weird thing I noticed while playing with camcontrol is I get an err= or=3D on access rate. > Sun=23 camcontrol inquiry da0 > pass0: Fixed Direct Access SCSI-4 device=20 > pass0: Serial Number =20 > camcontrol: error getting transfer settings >=20 >=20 > Thanks in advance >=20 > Nicolas >=20 >=20 > Here's my config (feel free to ask for more info): > Sun=23 cat /etc/iscsi.conf=20 > stephano =7B > authmethod =3D None > TargetName =3D iqn.2010-5.com.****:RAID.iscsi0.vg0.store > TargetAddress =3D 10.0.2.55:3260,1 > tags =3D 64> =7D >=20 > Sun=23 sysctl net.iscsi_initiator > net.iscsi_initiator.driver_version: 2.2.4 > net.iscsi_initiator.isid: =80DIB00> net.iscsi_initiator.sessions: 1 > net.iscsi_initiator.0.targetname: iqn.2010-5.com****:RAID.iscsi0.vg0.st= or=3De > net.iscsi_initiator.0.targeaddress: 10.0.2.55 > net.iscsi_initiator.0.stats: recv=3D46460 sent=3D46460 flags=3D0x000003= 9f=3D pdus-alloc=3D0 pdus-max=3D5 cws=3D33 cmd=3Db57b exp=3Db57b max=3Db5= 9b st=3Dat=3Db57b itt=3Db57b> net.iscsi_initiator.0.douio: 0 > net.iscsi_initiator.0.pid: 1608 hi Nicolas, have you tried increasing net.inet.tcp.recvspace net.inet.tcp.sendspace also what is the target? danny From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 11:07:07 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 925C41065672 for ; Mon, 17 May 2010 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 803798FC29 for ; Mon, 17 May 2010 11:07:07 +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 o4HB77lI015863 for ; Mon, 17 May 2010 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4HB767E015861 for freebsd-scsi@FreeBSD.org; Mon, 17 May 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 May 2010 11:07:06 GMT Message-Id: <201005171107.o4HB767E015861@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, 17 May 2010 11:07:07 -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/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri p kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping f kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 39 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 15:16:34 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 7DDD41065677 for ; Mon, 17 May 2010 15:16:34 +0000 (UTC) (envelope-from holm@pegasus.freibergnet.de) Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.freebsd.org (Postfix) with ESMTP id 08F098FC1F for ; Mon, 17 May 2010 15:16:33 +0000 (UTC) Received: from pegasus.freibergnet.de (localhost [127.0.0.1]) by pegasus.freibergnet.de (8.14.4/8.14.4) with ESMTP id o4HF5Dbh093603 for ; Mon, 17 May 2010 17:05:14 +0200 (CEST) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.14.4/8.14.4/Submit) id o4HF5DiJ093602 for freebsd-scsi@freebsd.org; Mon, 17 May 2010 17:05:13 +0200 (CEST) (envelope-from holm) Date: Mon, 17 May 2010 17:05:13 +0200 From: Holm Tiffe To: freebsd-scsi@freebsd.org Message-ID: <20100517150513.GA93298@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Organization: FreibergNet Internet Services, TSHT Priority: normal X-Phone: +49-3731-74222 X-Mobile: +49-172-8790741 X-Fax: +49-3731-74200 Subject: Problems with DLT on 8-Stable X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: holm@freibergnet.de List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 15:16:34 -0000 Hi, I've running 8-stable for a while now, upgradet from 6.4 a fiew months ago. Since then, I've problems with dump to my "Quantum DLT4000 CC28". While dumping a larger filesystem as the tape can hold, I always get this after changing the tape: # dump L0uaf /dev/nsa1 -b 64 -C 16 /data [..] DUMP: 66.63% done, finished in 2:22 at Mon May 17 17:04:58 2010 DUMP: 67.69% done, finished in 2:18 at Mon May 17 17:05:41 2010 DUMP: 68.73% done, finished in 2:14 at Mon May 17 17:06:27 2010 DUMP: End of tape detected DUMP: Closing /dev/nsa1 DUMP: Change Volumes: Mount volume #2 DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes DUMP: Volume 2 begins with blocks from inode 15003275 DUMP: EOT detected at start of the tape! DUMP: The ENTIRE dump is aborted. No, it's not he tape, nor the DLT. Has anyone seen this? How can I fix this? Kind Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, info@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741 From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 16:18:45 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 34686106566B for ; Mon, 17 May 2010 16:18:45 +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 F03498FC17 for ; Mon, 17 May 2010 16:18:44 +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 o4HGIiAr058007; Mon, 17 May 2010 09:18:44 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF16C62.6010104@feral.com> Date: Mon, 17 May 2010 09:18:42 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Holm Tiffe , freebsd-scsi@freebsd.org References: <20100517150513.GA93298@pegasus.freiberg-net.de> In-Reply-To: <20100517150513.GA93298@pegasus.freiberg-net.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 17 May 2010 09:18:44 -0700 (PDT) Cc: Subject: Re: Problems with DLT on 8-Stable 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, 17 May 2010 16:18:45 -0000 How about some more information, like anything noted in /var/log/messages? > No, it's not he tape, nor the DLT. > > Has anyone seen this? How can I fix this? > > Kind Regards, > > Holm > From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 17:00: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 01A4210657CE for ; Mon, 17 May 2010 17:00:00 +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 BE6938FC1C for ; Mon, 17 May 2010 16:59:59 +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 o4HGxwvg058423; Mon, 17 May 2010 09:59:59 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF1760D.6060903@feral.com> Date: Mon, 17 May 2010 09:59:57 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Long References: <4BEDF5BD.9040502@feral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 17 May 2010 09:59:59 -0700 (PDT) Cc: freebsd-scsi@freebsd.org Subject: Re: addition of an XPT_SCAN_TGT code 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, 17 May 2010 17:00:00 -0000 Turns out the XPT_SCAN_TGT adds some blockage for actual reboots, haha. Trying to sort that out now. From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 17:59:30 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 DC7C51065670 for ; Mon, 17 May 2010 17:59:29 +0000 (UTC) (envelope-from holm@pegasus.freibergnet.de) Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.freebsd.org (Postfix) with ESMTP id AA7788FC13 for ; Mon, 17 May 2010 17:59:28 +0000 (UTC) Received: from pegasus.freibergnet.de (localhost [127.0.0.1]) by pegasus.freibergnet.de (8.14.4/8.14.4) with ESMTP id o4HHxNJd096537; Mon, 17 May 2010 19:59:24 +0200 (CEST) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.14.4/8.14.4/Submit) id o4HHxNXo096536; Mon, 17 May 2010 19:59:23 +0200 (CEST) (envelope-from holm) Date: Mon, 17 May 2010 19:59:23 +0200 From: Holm Tiffe To: Matthew Jacob Message-ID: <20100517175923.GA96425@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , Matthew Jacob , freebsd-scsi@freebsd.org References: <20100517150513.GA93298@pegasus.freiberg-net.de> <4BF16C62.6010104@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BF16C62.6010104@feral.com> User-Agent: Mutt/1.4.2.3i Organization: FreibergNet Internet Services, TSHT Priority: normal X-Phone: +49-3731-74222 X-Mobile: +49-172-8790741 X-Fax: +49-3731-74200 Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with DLT on 8-Stable X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: holm@freibergnet.de List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 17:59:30 -0000 Matthew Jacob wrote: > How about some more information, like anything noted in /var/log/messages? > >No, it's not he tape, nor the DLT. > > > >Has anyone seen this? How can I fix this? > > > >Kind Regards, > > > >Holm > > You can get what you ever want, but there is no message in /var/log/messages regarding this. The OS is from yesterday afternoon, booting with the tape loaded from the test before is generating this single line in /var/log/messages: May 17 09:29:20 unicorn kernel: (sa1:ahc0:0:6:0): 65536-byte tape record bigger than supplied buffer Here comes the dmesg.boot: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #7: Mon May 17 08:56:03 CEST 2010 holm@unicorn.tsht.lan:/data/FreeBSD/obj/data/FreeBSD/src/sys/UNICORN i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3000+ (2109.49-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Family = 6 Model = a Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 2147483648 (2048 MB) avail memory = 2092113920 (1995 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 128M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xd8000000-0xdfffffff,0xe9000000-0xe900ffff irq 15 at device 0.0 on pci1 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 128MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci1: mem 0xe0000000-0xe7ffffff,0xe9010000-0xe901ffff at device 0.1 on pci1 de0: port 0xa000-0xa07f mem 0xeb003000-0xeb00307f irq 15 at device 9.0 on pci0 de0: Cogent 21040 [10Mb/s] pass 2.3 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:92:90:09:8d de0: [ITHREAD] puc0: port 0xa400-0xa407,0xa800-0xa807,0xac00-0xac1f mem 0xeb000000-0xeb000fff,0xeb001000-0xeb001fff irq 5 at device 10.0 on pci0 puc0: [FILTER] uart2: <16550 or compatible> on puc0 uart2: [FILTER] uart3: <16550 or compatible> on puc0 uart3: [FILTER] ahc0: port 0xb000-0xb0ff mem 0xeb002000-0xeb002fff irq 11 at device 11.0 on pci0 ahc0: [ITHREAD] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs amd0: port 0xb400-0xb47f irq 15 at device 13.0 on pci0 amd0: [GIANT-LOCKED] amd0: [ITHREAD] uhci0: port 0xb800-0xb81f irq 15 at device 16.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xbc00-0xbc1f irq 15 at device 16.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xc000-0xc01f irq 5 at device 16.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xeb004000-0xeb0040ff irq 11 at device 16.3 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcm0: port 0xc800-0xc8ff irq 5 at device 17.5 on pci0 pcm0: [ITHREAD] pcm0: pcm0: rl0: port 0xcc00-0xccff mem 0xeb005000-0xeb0050ff irq 5 at device 19.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0d:61:c3:c4:5a rl0: [ITHREAD] atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fd1: <1200-KB 5.25" drive> on fdc0 drive 1 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2109486622 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered (probe6:ahc0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe6:ahc0:0:6:0): CAM status: SCSI Status Error (probe6:ahc0:0:6:0): SCSI status: Check Condition (probe6:ahc0:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe5:ahc0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe5:ahc0:0:5:0): CAM status: SCSI Status Error (probe5:ahc0:0:5:0): SCSI status: Check Condition (probe5:ahc0:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (probe5:ahc0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe5:ahc0:0:5:0): CAM status: SCSI Status Error (probe5:ahc0:0:5:0): SCSI status: Check Condition (probe5:ahc0:0:5:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) sa0 at ahc0 bus 0 scbus0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers sa1 at ahc0 bus 0 scbus0 target 6 lun 0 sa1: Removable Sequential Access SCSI-CCS device sa1: 3.300MB/s transfers da0 at ahc0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da0: Command Queueing enabled da0: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da1 at ahc0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da1: Command Queueing enabled da1: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da2 at ahc0 bus 0 scbus0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da2: Command Queueing enabled da2: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) da3 at ahc0 bus 0 scbus0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da3: Command Queueing enabled da3: 70006MB (143374000 512 byte sectors: 255H 63S/T 8924C) GEOM_CONCAT: Device gc0d created (id=2065581164). GEOM_CONCAT: Disk da0d attached to gc0d. GEOM_CONCAT: Device data created (id=2038144655). GEOM_CONCAT: Disk da0g attached to data. GEOM_MIRROR: Device mirror/gm0a launched (2/2). GEOM_CONCAT: Disk da1d attached to gc0d. GEOM_CONCAT: Device gc0d activated. GEOM_MIRROR: Device mirror/gm0e launched (2/2). GEOM_MIRROR: Device mirror/gm0f launched (2/2). GEOM_CONCAT: Disk da1g attached to data. GEOM_CONCAT: Disk da2a attached to data. GEOM_CONCAT: Disk da2b attached to data. GEOM_CONCAT: Device data activated. Trying to mount root from ufs:/dev/mirror/gm0a Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, info@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741 From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 18:24:04 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 D4245106564A for ; Mon, 17 May 2010 18:24:04 +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 B167C8FC1B for ; Mon, 17 May 2010 18:24:04 +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 o4HIO3IU059922; Mon, 17 May 2010 11:24:03 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF189BE.9000008@feral.com> Date: Mon, 17 May 2010 11:23:58 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Holm Tiffe , Matthew Jacob , freebsd-scsi@freebsd.org References: <20100517150513.GA93298@pegasus.freiberg-net.de> <4BF16C62.6010104@feral.com> <20100517175923.GA96425@pegasus.freiberg-net.de> In-Reply-To: <20100517175923.GA96425@pegasus.freiberg-net.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 17 May 2010 11:24:04 -0700 (PDT) Cc: Subject: Re: Problems with DLT on 8-Stable 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, 17 May 2010 18:24:04 -0000 Holm Tiffe wrote: > You can get what you ever want, but there is no message in > /var/log/messages regarding this. > The messages state a "Media Not Present" error, on top of two TUR conditions. Do any of these correlate to you changing the tapes? The '65536-byte tape record' message is interesting. For some reason, sa is receiving a write that is no 64K in size, and the tape is in 'fixed' 64K block mode. Can you send the output of 'mt -f /dev/nsa1 status' with a tape loaded. More than that I'll have to dig up a tape drive and attach it- I haven't used on on FreeBSD in years. From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 18:55:08 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 6C8EA1065673 for ; Mon, 17 May 2010 18:55:07 +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 5739A8FC19 for ; Mon, 17 May 2010 18:55:07 +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 o4HIt6Ef060158 for ; Mon, 17 May 2010 11:55:06 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF19105.3000208@feral.com> Date: Mon, 17 May 2010 11:55:01 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BEB87B8.1070104@feral.com> In-Reply-To: <4BEB87B8.1070104@feral.com> Content-Type: multipart/mixed; boundary="------------090805010709030802050502" X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 17 May 2010 11:55:06 -0700 (PDT) Subject: addition of an XPT_SCAN_TGT code, rev 2 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 18:55:08 -0000 This is a multi-part message in MIME format. --------------090805010709030802050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Incorporating feedback and finding and fixing an amusing bug that kept the system from booting (but did not appear to affect changes while the system was running). --------------090805010709030802050502 Content-Type: text/plain; name="TGT_SCAN.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="TGT_SCAN.diff" diff -r 85c0fa25a2fc sys/cam/ata/ata_xpt.c --- a/sys/cam/ata/ata_xpt.c Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/ata/ata_xpt.c Fri May 14 18:14:46 2010 -0700 @@ -1189,6 +1189,7 @@ ("xpt_scan_bus\n")); switch (request_ccb->ccb_h.func_code) { case XPT_SCAN_BUS: + case XPT_SCAN_TGT: /* Find out the characteristics of the bus */ work_ccb = xpt_alloc_ccb_nowait(); if (work_ccb == NULL) { @@ -1530,6 +1531,7 @@ break; } case XPT_SCAN_BUS: + case XPT_SCAN_TGT: ata_scan_bus(start_ccb->ccb_h.path->periph, start_ccb); break; case XPT_SCAN_LUN: diff -r 85c0fa25a2fc sys/cam/cam_ccb.h --- a/sys/cam/cam_ccb.h Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/cam_ccb.h Mon May 17 11:47:24 2010 -0700 @@ -184,6 +184,11 @@ /* * Set SIM specific knob values. */ + + XPT_SCAN_TGT = 0x1E | XPT_FC_QUEUED | XPT_FC_USER_CCB + | XPT_FC_XPT_ONLY, + /* Scan Target */ + /* HBA engine commands 0x20->0x2F */ XPT_ENG_INQ = 0x20 | XPT_FC_XPT_ONLY, /* HBA engine feature inquiry */ diff -r 85c0fa25a2fc sys/cam/cam_xpt.c --- a/sys/cam/cam_xpt.c Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/cam_xpt.c Fri May 14 18:14:46 2010 -0700 @@ -463,6 +463,13 @@ case XPT_PATH_INQ: case XPT_ENG_INQ: case XPT_SCAN_LUN: + case XPT_SCAN_TGT: + if (inccb->ccb_h.func_code == XPT_SCAN_TGT && + (inccb->ccb_h.target_id == CAM_TARGET_WILDCARD || + (inccb->ccb_h.target_lun != CAM_LUN_WILDCARD))) { + error = EINVAL; + break; + } ccb = xpt_alloc_ccb(); @@ -839,11 +846,21 @@ struct ccb_hdr *hdr; /* Prepare request */ - if (ccb->ccb_h.path->target->target_id == CAM_TARGET_WILDCARD || + if (ccb->ccb_h.path->target->target_id == CAM_TARGET_WILDCARD && ccb->ccb_h.path->device->lun_id == CAM_LUN_WILDCARD) ccb->ccb_h.func_code = XPT_SCAN_BUS; - else + else if (ccb->ccb_h.path->target->target_id != CAM_TARGET_WILDCARD && + ccb->ccb_h.path->device->lun_id == CAM_LUN_WILDCARD) + ccb->ccb_h.func_code = XPT_SCAN_TGT; + else if (ccb->ccb_h.path->target->target_id != CAM_TARGET_WILDCARD && + ccb->ccb_h.path->device->lun_id != CAM_LUN_WILDCARD) ccb->ccb_h.func_code = XPT_SCAN_LUN; + else { + xpt_print(ccb->ccb_h.path, "illegal scan path\n"); + xpt_free_path(ccb->ccb_h.path); + xpt_free_ccb(ccb); + return; + } ccb->ccb_h.ppriv_ptr1 = ccb->ccb_h.cbfcnp; ccb->ccb_h.cbfcnp = xpt_rescan_done; xpt_setup_ccb(&ccb->ccb_h, ccb->ccb_h.path, CAM_PRIORITY_XPT); diff -r 85c0fa25a2fc sys/cam/scsi/scsi_xpt.c --- a/sys/cam/scsi/scsi_xpt.c Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/scsi/scsi_xpt.c Fri May 14 18:14:46 2010 -0700 @@ -1487,12 +1487,13 @@ ("scsi_scan_bus\n")); switch (request_ccb->ccb_h.func_code) { case XPT_SCAN_BUS: + case XPT_SCAN_TGT: { scsi_scan_bus_info *scan_info; union ccb *work_ccb, *reset_ccb; struct cam_path *path; u_int i; - u_int max_target; + u_int low_target, max_target; u_int initiator_id; /* Find out the characteristics of the bus */ @@ -1557,13 +1558,18 @@ /* Cache on our stack so we can work asynchronously */ max_target = scan_info->cpi->max_target; + low_target = 0; initiator_id = scan_info->cpi->initiator_id; /* * We can scan all targets in parallel, or do it sequentially. */ - if (scan_info->cpi->hba_misc & PIM_SEQSCAN) { + + if (request_ccb->ccb_h.func_code == XPT_SCAN_TGT) { + max_target = low_target = request_ccb->ccb_h.target_id; + scan_info->counter = 0; + } else if (scan_info->cpi->hba_misc & PIM_SEQSCAN) { max_target = 0; scan_info->counter = 0; } else { @@ -1573,7 +1579,7 @@ } } - for (i = 0; i <= max_target; i++) { + for (i = low_target; i <= max_target; i++) { cam_status status; if (i == initiator_id) continue; @@ -1688,7 +1694,9 @@ hop_again: done = 0; - if (scan_info->cpi->hba_misc & PIM_SEQSCAN) { + if (scan_info->request_ccb->ccb_h.func_code == XPT_SCAN_TGT) { + done = 1; + } else if (scan_info->cpi->hba_misc & PIM_SEQSCAN) { scan_info->counter++; if (scan_info->counter == scan_info->cpi->initiator_id) { @@ -2009,6 +2017,7 @@ break; } case XPT_SCAN_BUS: + case XPT_SCAN_TGT: scsi_scan_bus(start_ccb->ccb_h.path->periph, start_ccb); break; case XPT_SCAN_LUN: diff -r 85c0fa25a2fc sys/dev/isp/isp_freebsd.c --- a/sys/dev/isp/isp_freebsd.c Fri May 14 15:55:34 2010 -0700 +++ b/sys/dev/isp/isp_freebsd.c Fri May 14 18:14:46 2010 -0700 @@ -3886,19 +3889,14 @@ } /* - * Allocate a CCB, create a wildcard path for this bus/target and schedule a rescan. + * Allocate a CCB, create a wildcard path for this target and schedule a rescan. */ ccb = xpt_alloc_ccb_nowait(); if (ccb == NULL) { isp_prt(isp, ISP_LOGWARN, "Chan %d unable to alloc CCB for rescan", chan); return; } - /* - * xpt_rescan only honors wildcard in the target field. - * Scan the whole bus instead of target, which will then - * force a scan of all luns. - */ - if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, cam_sim_path(fc->sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { + if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, cam_sim_path(fc->sim), tgt, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { isp_prt(isp, ISP_LOGWARN, "unable to create path for rescan"); xpt_free_ccb(ccb); return; --------------090805010709030802050502-- From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 19:09: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 0997B1065675 for ; Mon, 17 May 2010 19:09:14 +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 B37068FC0A for ; Mon, 17 May 2010 19:09:13 +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 o4HJ9D4N060250 for ; Mon, 17 May 2010 12:09:13 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF19453.8090801@feral.com> Date: Mon, 17 May 2010 12:09:07 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: multipart/mixed; boundary="------------040108090607020707030507" X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Mon, 17 May 2010 12:09:13 -0700 (PDT) Subject: going rogue: incorporating REPORT_LUNS into the SCSI probe sequence 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, 17 May 2010 19:09:14 -0000 This is a multi-part message in MIME format. --------------040108090607020707030507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This one is a bit rougher than the others, but I'd like to encourage some discussion about this. The problems presented by not using REPORT LUNS have been getting uglier and uglier. Any kind of sparse lun arrangement for large JBODs or RAID units just makes life very painful. These changes manage REPORT LUNS for devices > SPC2, and even manage changes in the list. These changes do *not* address the edge case of having no attached LUN 0 (which has been known to happen- it's not illegal). I haven't quite finished putting together an action based upon the LUN INVENTORY MAY HAVE CHANGED ASC/ASCQ, and testing has been somewhat light. Still...... --------------040108090607020707030507 Content-Type: text/plain; name="REPORT_LUNS.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="REPORT_LUNS.diff" diff -r 85c0fa25a2fc sys/cam/cam_xpt.c --- a/sys/cam/cam_xpt.c Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/cam_xpt.c Mon May 17 12:01:11 2010 -0700 @@ -4189,6 +4189,7 @@ target->target_id = target_id; target->refcount = 1; target->generation = 0; + target->luns = NULL; timevalclear(&target->last_reset); /* * Hold a reference to our parent bus so it @@ -4220,6 +4221,8 @@ TAILQ_REMOVE(&target->bus->et_entries, target, links); target->bus->generation++; xpt_release_bus(target->bus); + if (target->luns) + free(target->luns, M_CAMXPT); free(target, M_CAMXPT); } } diff -r 85c0fa25a2fc sys/cam/cam_xpt_internal.h --- a/sys/cam/cam_xpt_internal.h Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/cam_xpt_internal.h Mon May 17 12:01:11 2010 -0700 @@ -135,6 +135,8 @@ u_int32_t refcount; u_int generation; struct timeval last_reset; + u_int rpl_size; + struct scsi_report_luns_data *luns; }; /* diff -r 85c0fa25a2fc sys/cam/scsi/scsi_xpt.c --- a/sys/cam/scsi/scsi_xpt.c Fri May 14 15:55:34 2010 -0700 +++ b/sys/cam/scsi/scsi_xpt.c Mon May 17 12:01:11 2010 -0700 @@ -75,6 +75,7 @@ #define CAM_QUIRK_NOSERIAL 0x02 #define CAM_QUIRK_HILUNS 0x04 #define CAM_QUIRK_NOHILUNS 0x08 +#define CAM_QUIRK_NORPTLUNS 0x10 u_int mintags; u_int maxtags; }; @@ -88,6 +89,21 @@ "allow search above LUN 7 for SCSI3 and greater devices"); #define CAM_SCSI2_MAXLUN 8 +#define CAM_CAN_GET_SIMPLE_LUN(x, i) \ + ((((x)->luns[i].lundata[0] & RPL_LUNDATA_ATYP_MASK) == \ + RPL_LUNDATA_ATYP_PERIPH) || \ + (((x)->luns[i].lundata[0] & RPL_LUNDATA_ATYP_MASK) == \ + RPL_LUNDATA_ATYP_FLAT)) +#define CAM_GET_SIMPLE_LUN(lp, i, lval) \ + if (((lp)->luns[(i)].lundata[0] & RPL_LUNDATA_ATYP_MASK) == \ + RPL_LUNDATA_ATYP_PERIPH) { \ + (lval) = (lp)->luns[(i)].lundata[1]; \ + } else { \ + (lval) = (lp)->luns[(i)].lundata[0]; \ + (lval) &= RPL_LUNDATA_FLAT_LUN_MASK; \ + (lval) <<= 8; \ + (lval) |= (lp)->luns[(i)].lundata[1]; \ + } /* * If we're not quirked to search <= the first 8 luns * and we are either quirked to search above lun 8, @@ -120,6 +136,7 @@ PROBE_TUR, PROBE_INQUIRY, /* this counts as DV0 for Basic Domain Validation */ PROBE_FULL_INQUIRY, + PROBE_REPORT_LUNS, PROBE_MODE_SENSE, PROBE_SERIAL_NUM_0, PROBE_SERIAL_NUM_1, @@ -134,6 +151,7 @@ "PROBE_TUR", "PROBE_INQUIRY", "PROBE_FULL_INQUIRY", + "PROBE_REPORT_LUNS", "PROBE_MODE_SENSE", "PROBE_SERIAL_NUM_0", "PROBE_SERIAL_NUM_1", @@ -531,6 +549,8 @@ static int proberequestbackoff(struct cam_periph *periph, struct cam_ed *device); static void probedone(struct cam_periph *periph, union ccb *done_ccb); +static void probe_purge_old(struct cam_path *path, + struct scsi_report_luns_data *new); static void probecleanup(struct cam_periph *periph); static void scsi_find_quirk(struct cam_ed *device); static void scsi_scan_bus(struct cam_periph *periph, union ccb *ccb); @@ -689,6 +709,7 @@ softc = (probe_softc *)periph->softc; csio = &start_ccb->csio; +again: switch (softc->action) { case PROBE_TUR: @@ -777,6 +798,27 @@ /*timeout*/60 * 1000); break; } + case PROBE_REPORT_LUNS: + { + void *rp; + + rp = malloc(periph->path->target->rpl_size, + M_CAMXPT, M_NOWAIT | M_ZERO); + if (rp == NULL) { + struct scsi_inquiry_data *inq_buf; + inq_buf = &periph->path->device->inq_data; + xpt_print(periph->path, + "Unable to alloc report luns storage\n"); + if (INQ_DATA_TQ_ENABLED(inq_buf)) + PROBE_SET_ACTION(softc, PROBE_MODE_SENSE); + else + PROBE_SET_ACTION(softc, PROBE_SERIAL_NUM_0); + goto again; + } + scsi_report_luns(csio, 4, probedone, MSG_SIMPLE_Q_TAG, + RPL_REPORT_DEFAULT, rp, periph->path->target->rpl_size, + SSD_FULL_SIZE, 60000); break; + } case PROBE_MODE_SENSE: { void *mode_buf; @@ -1075,7 +1117,18 @@ scsi_find_quirk(path->device); scsi_devise_transport(path); - if (INQ_DATA_TQ_ENABLED(inq_buf)) + + if (path->device->lun_id == 0 && + SID_ANSI_REV(inq_buf) > SCSI_REV_SPC2 && + (SCSI_QUIRK(path->device)->quirks & + CAM_QUIRK_NORPTLUNS) == 0) { + PROBE_SET_ACTION(softc, + PROBE_REPORT_LUNS); + /* + * Start with room for *one* lun. + */ + periph->path->target->rpl_size = 16; + } else if (INQ_DATA_TQ_ENABLED(inq_buf)) PROBE_SET_ACTION(softc, PROBE_MODE_SENSE); else @@ -1117,6 +1170,83 @@ status = CAM_REQ_CMP_ERR; break; } + case PROBE_REPORT_LUNS: + { + struct ccb_scsiio *csio; + struct scsi_report_luns_data *lp; + + csio = &done_ccb->csio; + + lp = (struct scsi_report_luns_data *)csio->data_ptr; + + if (status != CAM_REQ_CMP) { + if (PCHK_S(done_ccb, SF_RETRY_UA|SF_NO_PRINT, softc)) + return; + free(lp, M_CAMXPT); + lp = NULL; + } else { + u_int nlun, maxlun; + struct scsi_report_luns_data *newlp = NULL; + lun_id_t lun; + + nlun = scsi_4btoul(lp->length) / 8; + maxlun = (csio->dxfer_len / 8) - 1; + + /* + * If we have one lun, and it's lun 0, just + * do the standard probe sequence. + */ + if (nlun < 1) { + free(lp, M_CAMXPT); + lp = NULL; + } else if (nlun == 1 && + CAM_CAN_GET_SIMPLE_LUN(lp, 0)) { + CAM_GET_SIMPLE_LUN(lp, 0, lun); + if (lun != 0) { + newlp = lp; + } else { + free(lp, M_CAMXPT); + lp = NULL; + } + } else if (nlun > maxlun) { + /* + * Retry and cover all luns + */ + free(lp, M_CAMXPT); + path->target->rpl_size = (nlun << 3) + 8; + xpt_release_ccb(done_ccb); + xpt_schedule(periph, priority); + return; + } else { + newlp = lp; + } + if (newlp) { + /* + * If we have an old lun list, We can either retest luns + * that appear to have been dropped, or just nuke them. + * We'll opt for the latter. This function will also + * install the new list in the target structure. + */ + probe_purge_old(path, newlp); + } + } + if (path->device->flags & CAM_DEV_INQUIRY_DATA_VALID) { + struct scsi_inquiry_data *inq_buf; + inq_buf = &path->device->inq_data; + if (INQ_DATA_TQ_ENABLED(inq_buf)) + PROBE_SET_ACTION(softc, PROBE_MODE_SENSE); + else + PROBE_SET_ACTION(softc, PROBE_SERIAL_NUM_0); + xpt_release_ccb(done_ccb); + xpt_schedule(periph, priority); + return; + } + if (lp) { + free(lp, M_CAMXPT); + } + status = CAM_REQ_CMP_ERR; + break; + } case PROBE_MODE_SENSE: { struct ccb_scsiio *csio; @@ -1426,6 +1556,66 @@ } static void +probe_purge_old(struct cam_path *path, struct scsi_report_luns_data *new) +{ + struct cam_path *tp; + struct scsi_report_luns_data *old; + u_int idx1, idx2, nlun_old, nlun_new, this_lun; + u_int8_t *ol, *nl; + + if (path->target == NULL) { + return; + } + if (path->target->luns == NULL) { + path->target->luns = new; + return; + } + old = path->target->luns; + nlun_old = scsi_4btoul(old->length) / 8; + nlun_new = scsi_4btoul(new->length) / 8; + + /* + * We are not going to assume sorted lists. Deal. + */ + for (idx1 = 0; idx1 < nlun_old; idx1++) { + ol = old->luns[idx1].lundata; + for (idx2 = 0; idx2 < nlun_new; idx2++) { + nl = new->luns[idx2].lundata; + if (memcmp(nl, ol, 8) == 0) { + break; + } + } + if (idx2 < nlun_new) { + continue; + } + /* + * An 'old' item not in the 'new' list. + * Nuke it. Except that if it is lun 0, + * that would be what the probe state + * machine is currently working on, + * so we won't do that. + * + * We also cannot nuke it if it is + * not in a lun format we understand. + */ + if (!CAM_CAN_GET_SIMPLE_LUN(old, idx1)) { + continue; + } + CAM_GET_SIMPLE_LUN(old, idx1, this_lun); + if (this_lun == 0) { + continue; + } + if (xpt_create_path(&tp, NULL, xpt_path_path_id(path), + xpt_path_target_id(path), this_lun) == CAM_REQ_CMP) { + xpt_async(AC_LOST_DEVICE, tp, NULL); + xpt_free_path(tp); + } + } + free(old, M_CAMXPT); + path->target->luns = new; +} + +static void probecleanup(struct cam_periph *periph) { free(periph->softc, M_CAMXPT); @@ -1473,6 +1663,7 @@ union ccb *request_ccb; struct ccb_pathinq *cpi; int counter; + int lunindex; } scsi_scan_bus_info; /* @@ -1554,6 +1745,7 @@ } scan_info->request_ccb = request_ccb; scan_info->cpi = &work_ccb->cpi; + scan_info->lunindex = 0; /* Cache on our stack so we can work asynchronously */ max_target = scan_info->cpi->max_target; @@ -1615,6 +1807,9 @@ cam_status status; struct cam_path *path; scsi_scan_bus_info *scan_info; + struct cam_et *target; + struct cam_ed *device; + int next_target; path_id_t path_id; target_id_t target_id; lun_id_t lun_id; @@ -1630,9 +1825,34 @@ lun_id = request_ccb->ccb_h.target_lun; xpt_action(request_ccb); - if (request_ccb->ccb_h.status != CAM_REQ_CMP) { - struct cam_ed *device; - struct cam_et *target; + target = request_ccb->ccb_h.path->target; + next_target = 1; + + if (target->luns) { + u_int nluns = scsi_4btoul(target->luns->length) / 8; + /* + * We could check to see whether or not the current probe + * finishing and is lun 0. If it were marked as failed, + * we could check against the first lunindex- we just (barely) + * might have a target with nothing at lun 0. This is really + * contorted, but oddly enough a valid edge case. However, + * we really can't get here w/o changing the probedone + * handling of inquiry so that it will accept non-connected + * luns. It's just too much of an edge case to worry about. + * + * Just see if we have more luns to scan. We're not going to + * care about success or failure here for any one probe because + * we're just simply poking at the list the target gave us. + */ + if (scan_info->lunindex++ < nluns) { + if (CAM_CAN_GET_SIMPLE_LUN(target->luns, + scan_info->lunindex)) { + CAM_GET_SIMPLE_LUN(target->luns, + scan_info->lunindex, lun_id); + next_target = 0; + } + } + } else if (request_ccb->ccb_h.status != CAM_REQ_CMP) { int phl; /* @@ -1641,7 +1861,6 @@ * target that might have "gone away", go onto * the next lun. */ - target = request_ccb->ccb_h.path->target; /* * We may touch devices that we don't * hold references too, so ensure they @@ -1657,11 +1876,12 @@ device = TAILQ_NEXT(device, links); } if ((lun_id != 0) || (device != NULL)) { - if (lun_id < (CAM_SCSI2_MAXLUN-1) || phl) + if (lun_id < (CAM_SCSI2_MAXLUN-1) || phl) { lun_id++; + next_target = 0; + } } } else { - struct cam_ed *device; device = request_ccb->ccb_h.path->device; @@ -1669,8 +1889,10 @@ CAM_QUIRK_NOLUNS) == 0) { /* Try the next lun */ if (lun_id < (CAM_SCSI2_MAXLUN-1) - || CAN_SRCH_HI_DENSE(device)) + || CAN_SRCH_HI_DENSE(device)) { lun_id++; + next_target = 0; + } } } @@ -1682,10 +1904,10 @@ /* * Check to see if we scan any further luns. */ - if (lun_id == request_ccb->ccb_h.target_lun - || lun_id > scan_info->cpi->max_lun) { + if (next_target) { int done; + scan_info->lunindex = 0; hop_again: done = 0; if (scan_info->cpi->hba_misc & PIM_SEQSCAN) { --------------040108090607020707030507-- From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 20:09:02 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 82F141065672 for ; Mon, 17 May 2010 20:09:02 +0000 (UTC) (envelope-from holm@pegasus.freibergnet.de) Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7471E8FC1F for ; Mon, 17 May 2010 20:09:01 +0000 (UTC) Received: from pegasus.freibergnet.de (localhost [127.0.0.1]) by pegasus.freibergnet.de (8.14.4/8.14.4) with ESMTP id o4HK8vqT098768; Mon, 17 May 2010 22:08:57 +0200 (CEST) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.14.4/8.14.4/Submit) id o4HK8vnY098767; Mon, 17 May 2010 22:08:57 +0200 (CEST) (envelope-from holm) Date: Mon, 17 May 2010 22:08:57 +0200 From: Holm Tiffe To: Matthew Jacob Message-ID: <20100517200856.GB96425@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , Matthew Jacob , freebsd-scsi@freebsd.org References: <20100517150513.GA93298@pegasus.freiberg-net.de> <4BF16C62.6010104@feral.com> <20100517175923.GA96425@pegasus.freiberg-net.de> <4BF189BE.9000008@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BF189BE.9000008@feral.com> User-Agent: Mutt/1.4.2.3i Organization: FreibergNet Internet Services, TSHT Priority: normal X-Phone: +49-3731-74222 X-Mobile: +49-172-8790741 X-Fax: +49-3731-74200 Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with DLT on 8-Stable X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: holm@freibergnet.de List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 20:09:02 -0000 Matthew Jacob wrote: > Holm Tiffe wrote: > >You can get what you ever want, but there is no message in > >/var/log/messages regarding this. > > > The messages state a "Media Not Present" error, on top of two TUR > conditions. Did you mean this: (probe6:ahc0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe6:ahc0:0:6:0): CAM status: SCSI Status Error (probe6:ahc0:0:6:0): SCSI status: Check Condition (probe6:ahc0:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bu s device reset occurred) (probe5:ahc0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe5:ahc0:0:5:0): CAM status: SCSI Status Error (probe5:ahc0:0:5:0): SCSI status: Check Condition (probe5:ahc0:0:5:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bu s device reset occurred) (probe5:ahc0:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe5:ahc0:0:5:0): CAM status: SCSI Status Error (probe5:ahc0:0:5:0): SCSI status: Check Condition (probe5:ahc0:0:5:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) sa0 at ahc0 bus 0 scbus0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers If so, no, that has nothing todo with the DLT or the dump, 0:5:0 is a Tandberg QIC Streamer and the message was appearing while booting (/var/run/dmesg.boot) # camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 1 lun 0 (da1,pass1) at scbus0 target 2 lun 0 (da2,pass2) at scbus0 target 3 lun 0 (da3,pass3) at scbus0 target 5 lun 0 (sa0,pass4) at scbus0 target 6 lun 0 (sa1,pass5) > > Do any of these correlate to you changing the tapes? No. There is nothing on console or /var/log/messages after changing the tape. It is simple dump that complains there where an EOT on the new inserted tape. > > The '65536-byte tape record' message is interesting. For some reason, > sa is receiving a write that is no 64K in size, and the tape is in > 'fixed' 64K block mode. Hmm, I think the other way around. I've wrote 64K blocks with the last dump on the tape and somebody is trying to read with a smaller buffer.... Remember, I do dumps like this: dump L0uaf /dev/nsa1 -b 64 -C 16 /data where b is the Blocksize in k and C is the Cache size in Meg. > > Can you send the output of 'mt -f /dev/nsa1 status' with a tape loaded. # mt -f /dev/nsa1 status Mode Density Blocksize bpi Compression Current: 0x1a:DLTapeIV(20GB) variable 81633 IDRC ---------available modes--------- 0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC 1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC 2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC 3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 1 Record Number: 0 Residual Count 0 > > More than that I'll have to dig up a tape drive and attach it- I haven't > used on on FreeBSD in years. I'll test this on the old trusty Tandberg 8Gig QIC drive tomorrow and will post the results. Kind Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, info@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741 From owner-freebsd-scsi@FreeBSD.ORG Mon May 17 20:16:47 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 94C521065680 for ; Mon, 17 May 2010 20:16:47 +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 6C0B58FC16 for ; Mon, 17 May 2010 20:16:47 +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 o4HKGkTP047113; Mon, 17 May 2010 13:16:46 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF1A429.501@feral.com> Date: Mon, 17 May 2010 13:16:41 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) To: Holm Tiffe , Matthew Jacob , freebsd-scsi@freebsd.org References: <20100517150513.GA93298@pegasus.freiberg-net.de> <4BF16C62.6010104@feral.com> <20100517175923.GA96425@pegasus.freiberg-net.de> <4BF189BE.9000008@feral.com> <20100517200856.GB96425@pegasus.freiberg-net.de> In-Reply-To: <20100517200856.GB96425@pegasus.freiberg-net.de> 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]); Mon, 17 May 2010 13:16:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Problems with DLT on 8-Stable 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, 17 May 2010 20:16:47 -0000 # mt -f /dev/nsa1 status Mode Density Blocksize bpi Compression Current: 0x1a:DLTapeIV(20GB) variable 81633 IDRC ---------available modes--------- 0: 0x1a:DLTapeIV(20GB) variable 81633 IDRC 1: 0x1a:DLTapeIV(20GB) variable 81633 IDRC 2: 0x1a:DLTapeIV(20GB) variable 81633 IDRC 3: 0x1a:DLTapeIV(20GB) variable 81633 IDRC --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 1 Record Number: 0 Residual Count 0 Huh. Well, something is weird here and I suspect dump more than sa(4). More than that I'll have to dig up a tape drive and attach it- I haven't used on on FreeBSD in years. I'll test this on the old trusty Tandberg 8Gig QIC drive tomorrow and will post the results. Oh. God. Now. Not the Tandberg. OMG. Aiiiiiiiiiiiiiiiiiiiiiiiiiiiieeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeee!!!!!!!!!!!!!!!!!!!!!!!! From owner-freebsd-scsi@FreeBSD.ORG Tue May 18 07:29:38 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 ECB4C106566B for ; Tue, 18 May 2010 07:29:37 +0000 (UTC) (envelope-from holm@pegasus.freibergnet.de) Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7159E8FC08 for ; Tue, 18 May 2010 07:29:36 +0000 (UTC) Received: from pegasus.freibergnet.de (localhost [127.0.0.1]) by pegasus.freibergnet.de (8.14.4/8.14.4) with ESMTP id o4I7TWMe010753; Tue, 18 May 2010 09:29:32 +0200 (CEST) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.14.4/8.14.4/Submit) id o4I7TVu2010752; Tue, 18 May 2010 09:29:31 +0200 (CEST) (envelope-from holm) Date: Tue, 18 May 2010 09:29:31 +0200 From: Holm Tiffe To: Matthew Jacob Message-ID: <20100518072931.GA10575@pegasus.freiberg-net.de> Mail-Followup-To: Holm Tiffe , Matthew Jacob , freebsd-scsi@freebsd.org References: <20100517150513.GA93298@pegasus.freiberg-net.de> <4BF16C62.6010104@feral.com> <20100517175923.GA96425@pegasus.freiberg-net.de> <4BF189BE.9000008@feral.com> <20100517200856.GB96425@pegasus.freiberg-net.de> <4BF1A429.501@feral.com> <20100517203031.GA98817@pegasus.freiberg-net.de> <4BF1A7DB.9020203@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BF1A7DB.9020203@feral.com> User-Agent: Mutt/1.4.2.3i Organization: FreibergNet Internet Services, TSHT Priority: normal X-Phone: +49-3731-74222 X-Mobile: +49-172-8790741 X-Fax: +49-3731-74200 Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with DLT on 8-Stable X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: holm@freibergnet.de List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 07:29:38 -0000 Matthew Jacob wrote: > Holm Tiffe wrote: > >Matthew Jacob wrote: > > > >Huh? Im not a browser... > > > > > >What do you have against the Tandberg drive? > >This old thing has done a good job in the years before. > > > > It's a QIC drive, with fixed 512 byte sectors formatted on tape. The > Tandberg guys thought that they could impose variable length records on > top of that. I have large memories of pain, but the details have been lost. > > Hey, if it works for you.... Tandberg has many different kinds of firmware for the drives, and there are several QIC Models, 250mb,525mb,2,5G,5G,8G... The drive in my PC has flawlessly worked the years before, but I remeber that there where problems on older drives. But the Tandbergs have a working mechanic in difference to the Wangteks or similar.. It seems, ithat here is not that much difference to the DLT: # mt -f /dev/sa0.ctl status Mode Density Blocksize bpi Compression Current: 0x15:ECMA TC17 variable 45434 disabled ---------available modes--------- 0: 0x15:ECMA TC17 variable 45434 0x3 1: 0x15:ECMA TC17 variable 45434 0x3 2: 0x15:ECMA TC17 variable 45434 0x3 3: 0x15:ECMA TC17 variable 45434 0x3 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 2 Record Number: 0 Residual Count 0 (Magnum 1.2 Gig tape inserted) besides of that, the drive behaves exactly the same as the DLT. DUMP: 2.40% done, finished in 27:04 at Wed May 19 11:50:21 2010 DUMP: 2.70% done, finished in 27:00 at Wed May 19 11:51:33 2010 DUMP: 3.00% done, finished in 26:56 at Wed May 19 11:52:02 2010 DUMP: End of tape detected DUMP: Closing /dev/nsa0 DUMP: Change Volumes: Mount volume #2 DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes DUMP: Volume 2 begins with blocks from inode 2779313 DUMP: EOT detected at start of the tape! DUMP: The ENTIRE dump is aborted. Dump detects that EOT before it is reading a byte from the drive, eg there are no transport noises after changing the tape and typing in "yes". After that, the tape moves a little around... At least the Tandberg drive has cleared now that the problem is not related to the DLT drive itself. And now? Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583 www.tsht.de, info@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741 From owner-freebsd-scsi@FreeBSD.ORG Tue May 18 08:20:49 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 BB7B11065673 for ; Tue, 18 May 2010 08:20:49 +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 7DC2E8FC19 for ; Tue, 18 May 2010 08:20:49 +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 o4I8KmGu051750; Tue, 18 May 2010 01:20:48 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF24DE0.9000100@feral.com> Date: Tue, 18 May 2010 01:20:48 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: holm@freibergnet.de References: <20100517150513.GA93298@pegasus.freiberg-net.de> <4BF16C62.6010104@feral.com> <20100517175923.GA96425@pegasus.freiberg-net.de> <4BF189BE.9000008@feral.com> <20100517200856.GB96425@pegasus.freiberg-net.de> <4BF1A429.501@feral.com> <20100517203031.GA98817@pegasus.freiberg-net.de> <4BF1A7DB.9020203@feral.com> <20100518072931.GA10575@pegasus.freiberg-net.de> In-Reply-To: <20100518072931.GA10575@pegasus.freiberg-net.de> Content-Type: text/plain; charset=ISO-8859-1; 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]); Tue, 18 May 2010 01:20:49 -0700 (PDT) Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with DLT on 8-Stable 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, 18 May 2010 08:20:49 -0000 Think time. > At least the Tandberg drive has cleared now that the problem is not > related to the DLT drive itself. And now? > > Regards, > > Holm > > From owner-freebsd-scsi@FreeBSD.ORG Tue May 18 22:20:01 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE8541065674 for ; Tue, 18 May 2010 22:20:01 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF078FC0A for ; Tue, 18 May 2010 22:20:01 +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 o4IMK0ZR046148 for ; Tue, 18 May 2010 15:20:00 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF3128B.4060005@feral.com> Date: Tue, 18 May 2010 15:19:55 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BF19453.8090801@feral.com> In-Reply-To: <4BF19453.8090801@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Tue, 18 May 2010 15:20:01 -0700 (PDT) Subject: Re: going rogue: incorporating REPORT_LUNS into the SCSI probe sequence 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, 18 May 2010 22:20:01 -0000 I'm going to withdraw this- I've found a couple of bugs, and I think it's important to actually deal with the case of no lun 0. > This one is a bit rougher than the others, but I'd like to encourage > some discussion about this. > > The problems presented by not using REPORT LUNS have been getting > uglier and uglier. Any kind of sparse lun arrangement for large JBODs > or RAID units just makes life very painful. > > These changes manage REPORT LUNS for devices > SPC2, and even manage > changes in the list. These changes do *not* address the edge case of > having no attached LUN 0 (which has been known to happen- it's not > illegal). > > I haven't quite finished putting together an action based upon the LUN > INVENTORY MAY HAVE CHANGED ASC/ASCQ, and testing has been somewhat light. > > Still...... > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Tue May 18 23:59:11 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 C1B661065672 for ; Tue, 18 May 2010 23:59:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8256E8FC0C for ; Tue, 18 May 2010 23:59:11 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o4INx5kT087983; Tue, 18 May 2010 17:59:05 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BF19453.8090801@feral.com> Date: Tue, 18 May 2010 17:59:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <76ECB3BB-6862-4DCE-8CC9-35ED1BC70BD2@samsco.org> References: <4BF19453.8090801@feral.com> To: Matthew Jacob X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: going rogue: incorporating REPORT_LUNS into the SCSI probe sequence 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, 18 May 2010 23:59:11 -0000 On May 17, 2010, at 1:09 PM, Matthew Jacob wrote: > This one is a bit rougher than the others, but I'd like to encourage = some discussion about this. >=20 > The problems presented by not using REPORT LUNS have been getting = uglier and uglier. Any kind of sparse lun arrangement for large JBODs or = RAID units just makes life very painful. >=20 > These changes manage REPORT LUNS for devices > SPC2, and even manage = changes in the list. These changes do *not* address the edge case of = having no attached LUN 0 (which has been known to happen- it's not = illegal). Under what circumstance is it not illegal? I thought that in SPI it was = always illegal. Granted, FC and other protocols might be different, = hence my curiosity. Scott From owner-freebsd-scsi@FreeBSD.ORG Wed May 19 00:05:51 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 4402A1065672 for ; Wed, 19 May 2010 00:05:51 +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 1E4C28FC0C for ; Wed, 19 May 2010 00:05:50 +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 o4J05oYs046627; Tue, 18 May 2010 17:05:50 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF32B5F.30809@feral.com> Date: Tue, 18 May 2010 17:05:51 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Scott Long References: <4BF19453.8090801@feral.com> <76ECB3BB-6862-4DCE-8CC9-35ED1BC70BD2@samsco.org> In-Reply-To: <76ECB3BB-6862-4DCE-8CC9-35ED1BC70BD2@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; 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]); Tue, 18 May 2010 17:05:50 -0700 (PDT) Cc: freebsd-scsi@freebsd.org Subject: Re: going rogue: incorporating REPORT_LUNS into the SCSI probe sequence 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, 19 May 2010 00:05:51 -0000 On 5/18/2010 4:59 PM, Scott Long wrote: > On May 17, 2010, at 1:09 PM, Matthew Jacob wrote: > > >> This one is a bit rougher than the others, but I'd like to encourage some discussion about this. >> >> The problems presented by not using REPORT LUNS have been getting uglier and uglier. Any kind of sparse lun arrangement for large JBODs or RAID units just makes life very painful. >> >> These changes manage REPORT LUNS for devices> SPC2, and even manage changes in the list. These changes do *not* address the edge case of having no attached LUN 0 (which has been known to happen- it's not illegal). >> > Under what circumstance is it not illegal? I thought that in SPI it was always illegal. Granted, FC and other protocols might be different, hence my curiosity. > AFAICT there is a difference of opinion on t10 about this. There's a lot of verbiage about things being attached to well known luns. From a practical point of view, it happens a lot. The LSI Santricity stack will create this run 100MB lun 0, but then most people just delete it after creating others, leaving nothing attached to lun 0. The main point here also is that luns that aren't "connected" (e.g., 0x7f types) should still respond to inquiry, request sense and REPORT LUNS. The code in scsi_xpt.c is something I'm going to have to make a little trickier to handle the case I'm referring to. From owner-freebsd-scsi@FreeBSD.ORG Thu May 20 11:46:12 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 34D5C1065673 for ; Thu, 20 May 2010 11:46:12 +0000 (UTC) (envelope-from anri@polynet.lviv.ua) Received: from pegasus.polynet.lviv.ua (pegasus.polynet.lviv.ua [195.22.112.6]) by mx1.freebsd.org (Postfix) with ESMTP id 23ACC8FC1D for ; Thu, 20 May 2010 11:46:10 +0000 (UTC) Received: (qmail 19870 invoked by uid 0); 20 May 2010 14:19:28 +0300 Received: from 195.22.112.10 by pegasus.lp.Lviv.ua (envelope-from , uid 0) with qmail-scanner-2.01 (clamdscan: 0.90.1/2691. spamassassin: 3.1.8. Clear:RC:1(195.22.112.10):. Processed in 0.015156 secs); 20 May 2010 11:19:28 -0000 Received: from orion.polynet.lviv.ua (HELO localhost) ([195.22.112.10]) (envelope-sender ) by pegasus.polynet.lviv.ua (qmail-ldap-1.03) with SMTP for ; 20 May 2010 11:19:28 -0000 Received: from vega.polynet.lviv.ua (vega.polynet.lviv.ua [195.22.112.3]) by globus.polynet.lviv.ua (Horde Framework) with HTTP; Thu, 20 May 2010 14:18:39 +0300 Message-ID: <20100520141839.42871afsgvlgab2n@globus.polynet.lviv.ua> Date: Thu, 20 May 2010 14:18:39 +0300 From: Andriy Kopystyansky To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) Subject: isp/qlogic reports controller SN instead of Logical Drive ID 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, 20 May 2010 11:46:12 -0000 Hi, people, I'm trying to launch a nice server on IBM Blade, and encountered =20 serious problem with multipath via Qlogic/ISP driver. I have IBM blade with two fibre channel adapters: isp0, isp1: Also i have storage IBM DS3400 with 2 FC-RAID controllers. Each =20 adapter has link to each FC-RAID. On the storage, I've created two logical disks (big disk 10G and small =20 one 6G), assigned to my blade, and sucessfully installed freebsd-8.0-amd64 on device da0. As expected, camcontrol shows da0-da7 devices (2 logical disks with 4 =20 pathes to each one). camcontrol readcap reports da0, da2, da4, da6 - belongs to 10G drive and da1, da3, da5, da7 - has 6G. Then I tried to build multipath volume on da1,da3,da5,da7. End here =20 problem starts: camcontrol inquiry da0 -S reports SX80801049 (which is actually serial =20 number of raid controller at DS3400, not an ID of 10G volume) camcontrol inquiry da1 -S also reports SX80801049... camcontrol inquiry da2 -S reports serial of second RAID (instead of =20 the same ID as da0)... and so on... camcontrol inquiry da4 -S reports first RAID serial (fine, this one =20 through isp1). In logs a lot of "ILLEGAL REQUEST asc:94,1" regarding da1, da2, da5, da6. As you can see, it allows me to have only one logical storage per RAID =20 controller :)) Help please. Thanks in advance. -- best regards, Andriy Kopystyansky ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-scsi@FreeBSD.ORG Thu May 20 13:56:44 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303181065672 for ; Thu, 20 May 2010 13:56:44 +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 E0ACC8FC1E for ; Thu, 20 May 2010 13:56:43 +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 o4KDuh2j016729 for ; Thu, 20 May 2010 06:56:43 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF53F9E.50305@feral.com> Date: Thu, 20 May 2010 06:56:46 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <20100520141839.42871afsgvlgab2n@globus.polynet.lviv.ua> In-Reply-To: <20100520141839.42871afsgvlgab2n@globus.polynet.lviv.ua> Content-Type: text/plain; charset=windows-1251; 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]); Thu, 20 May 2010 06:56:43 -0700 (PDT) Subject: Re: isp/qlogic reports controller SN instead of Logical Drive ID 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, 20 May 2010 13:56:44 -0000 On 5/20/2010 4:18 AM, Andriy Kopystyansky wrote: > Hi, people, > I'm trying to launch a nice server on IBM Blade, and encountered > serious problem with multipath via Qlogic/ISP driver. > > I have IBM blade with two fibre channel adapters: > isp0, isp1: > Also i have storage IBM DS3400 with 2 FC-RAID controllers. Each > adapter has link to each FC-RAID. > > On the storage, I've created two logical disks (big disk 10G and small > one 6G), assigned to my blade, > and sucessfully installed freebsd-8.0-amd64 on device da0. > As expected, camcontrol shows da0-da7 devices (2 logical disks with 4 > pathes to each one). > camcontrol readcap reports da0, da2, da4, da6 - belongs to 10G drive > and da1, da3, da5, da7 - has 6G. > Then I tried to build multipath volume on da1,da3,da5,da7. End here > problem starts: > camcontrol inquiry da0 -S reports SX80801049 (which is actually serial > number of raid controller at DS3400, not an ID of 10G volume) > camcontrol inquiry da1 -S also reports SX80801049... > camcontrol inquiry da2 -S reports serial of second RAID (instead of > the same ID as da0)... > and so on... > camcontrol inquiry da4 -S reports first RAID serial (fine, this one > through isp1). > > In logs a lot of "ILLEGAL REQUEST asc:94,1" regarding da1, da2, da5, > da6. It's not an HBA problem. You have Santricity storage underlying. 1. Santricity does not assign volume serial numbers. You'll get the same serial numbers no matter what for each lun. 2. The 94,1 issue is "You don't own this path". You need to set AVT (auto volume transfer) with exclusion. This is a problem, because LSI f/w is all over the map on this. It's currently set up to expect some kind of RDAC driver on the host which will control failover (since this is not really an active-active device). See if setting the host type to LINUXAVT (type 7, I think) works for you. Don't know what tools come with IBM for this. And I don't know if modifiying NVSRAM bytes for your device will work the same as for the ones I've seen- this would be to modify it so that access to the first and last 1MB of each lun doesn't trigger an AVT event. From owner-freebsd-scsi@FreeBSD.ORG Thu May 20 13:59:47 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 14690106564A for ; Thu, 20 May 2010 13:59:47 +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 CE0AD8FC20 for ; Thu, 20 May 2010 13:59:46 +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 o4KDxkUF016751 for ; Thu, 20 May 2010 06:59:46 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF54055.5060501@feral.com> Date: Thu, 20 May 2010 06:59:49 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <20100520141839.42871afsgvlgab2n@globus.polynet.lviv.ua> <4BF53F9E.50305@feral.com> In-Reply-To: <4BF53F9E.50305@feral.com> Content-Type: text/plain; charset=windows-1251; 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]); Thu, 20 May 2010 06:59:46 -0700 (PDT) Subject: Re: isp/qlogic reports controller SN instead of Logical Drive ID 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, 20 May 2010 13:59:47 -0000 > 1. Santricity does not assign volume serial numbers. You'll get the > same serial numbers no matter what for each lun. I misspoke on this. Yes, it does assign volume serial numbers, but, hey, you'll see the same one on all the different paths. From owner-freebsd-scsi@FreeBSD.ORG Fri May 21 22:00:13 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 571971065672 for ; Fri, 21 May 2010 22:00:13 +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 1CEA48FC0C for ; Fri, 21 May 2010 22:00:12 +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 o4LM09WQ003168 for ; Fri, 21 May 2010 15:00:09 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF70260.7060407@feral.com> Date: Fri, 21 May 2010 15:00:00 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Fri, 21 May 2010 15:00:12 -0700 (PDT) Subject: vhba/fake hba 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, 21 May 2010 22:00:13 -0000 I've extended my test virtual hba further- it's been incredibly useful for testing stuff. I'd like to put in the tree- but I'm guessing that /usr/src/tools/tests would be the right place. Any thoughts? From owner-freebsd-scsi@FreeBSD.ORG Fri May 21 22:14:31 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 08A30106566B for ; Fri, 21 May 2010 22:14:31 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id E7EF18FC0A for ; Fri, 21 May 2010 22:14:30 +0000 (UTC) Received: from [127.0.0.1] (proxy10.corp.re1.yahoo.com [69.147.105.206]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4LMEJCG008678; Fri, 21 May 2010 15:14:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=aJRkCu5XvT4pBJiABlkkfe1gmiRFLSeXmyHOd/LynOUDm75FVZG0zJ//GeMgQTqg From: Sean Bruno To: Matthew Jacob In-Reply-To: <4BF70260.7060407@feral.com> References: <4BF70260.7060407@feral.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 21 May 2010 15:14:19 -0700 Message-ID: <1274480059.2574.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-scsi@freebsd.org" Subject: Re: vhba/fake hba X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 22:14:31 -0000 On Fri, 2010-05-21 at 15:00 -0700, Matthew Jacob wrote: > I've extended my test virtual hba further- it's been incredibly useful > for testing stuff. > > I'd like to put in the tree- but I'm guessing that /usr/src/tools/tests > would be the right place. > > Any thoughts? > > ______________________________________________ I missed the link to the original source tree you're playing with. I'd be able to comment more if I knew from whence you're current building. Sean From owner-freebsd-scsi@FreeBSD.ORG Fri May 21 23:03:46 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936C01065676 for ; Fri, 21 May 2010 23:03:46 +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 942AD8FC16 for ; Fri, 21 May 2010 23:03:44 +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 o4LN3c2U006037 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 21 May 2010 16:03:41 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF71140.30401@feral.com> Date: Fri, 21 May 2010 16:03:28 -0700 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: <4BF70260.7060407@feral.com> <1274480059.2574.11.camel@localhost.localdomain> In-Reply-To: <1274480059.2574.11.camel@localhost.localdomain> 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, 21 May 2010 16:03:41 -0700 (PDT) Subject: Re: vhba/fake hba 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, 21 May 2010 23:03:46 -0000 The latest instantiation can be seen at http://people.freebsd.org/~mjacob/vhba > I missed the link to the original source tree you're playing with. > > I'd be able to comment more if I knew from whence you're current > building. > > Sean > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-scsi@FreeBSD.ORG Sat May 22 02:02:37 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 8F06C106566B for ; Sat, 22 May 2010 02:02:37 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1BDE88FC14 for ; Sat, 22 May 2010 02:02:36 +0000 (UTC) Received: by fxm4 with SMTP id 4so1728519fxm.13 for ; Fri, 21 May 2010 19:02:36 -0700 (PDT) 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:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yoE6o2fVUdcOvHmLe9DVPJXCo1tYh1rc7A30VXXOHig=; b=RKUMeJGL/L4uKkWdCcjLCKJ98OSKxESW7hoRDg4NSoo3Pv9qD6FE83zPub0DextVQ/ idFIa8abKbeS7LhvMNgfkYTC2I+U57YcYcH2KOCoxTG5As/uu2jURSpyiDnPgIJ4/oKf 9qA5WD+YnzHEHEuBksBM4YudZ1XliWw+LEN8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rqUCwnX7Pl8xlS+Hx5PpIBmDBXDoZJEieGIChHJb7jEFT42LPlNbaxcpGELnoG6Qaj O1V7Z8MnLr3zHB9hKSQ6LZRcfmMM5ymNqd4SFcPZC8iLss9LHOSXmraHSvyaT288paf5 gQ8f0lBqhYTVEqBobtPIeD5mD+az/bVb6s39Y= Received: by 10.223.22.145 with SMTP id n17mr2178768fab.23.1274493756019; Fri, 21 May 2010 19:02:36 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id u12sm7230902fah.16.2010.05.21.19.02.34 (version=SSLv3 cipher=RC4-MD5); Fri, 21 May 2010 19:02:35 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BF73B2A.1070804@FreeBSD.org> Date: Sat, 22 May 2010 05:02:18 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Matthew Jacob , freebsd-scsi@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: vhba/fake hba 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, 22 May 2010 02:02:37 -0000 Matthew Jacob wrote: > I've extended my test virtual hba further- it's been incredibly useful > for testing stuff. > > I'd like to put in the tree- but I'm guessing that /usr/src/tools/tests > would be the right place. > > Any thoughts? Nice hack framework. But looking on subject, my first thought was that it is something like OpenBSD's vscsi(4). -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Sat May 22 03:59:34 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 A3F091065673 for ; Sat, 22 May 2010 03:59:34 +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 4815A8FC0C for ; Sat, 22 May 2010 03:59:33 +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 o4M3xUcY007374 for ; Fri, 21 May 2010 20:59:32 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BF756A7.6070108@feral.com> Date: Fri, 21 May 2010 20:59:35 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BF73B2A.1070804@FreeBSD.org> In-Reply-To: <4BF73B2A.1070804@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; 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]); Fri, 21 May 2010 20:59:33 -0700 (PDT) Subject: Re: vhba/fake hba 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, 22 May 2010 03:59:34 -0000 On 5/21/2010 7:02 PM, Alexander Motin wrote: > Matthew Jacob wrote: > >> I've extended my test virtual hba further- it's been incredibly useful >> for testing stuff. >> >> I'd like to put in the tree- but I'm guessing that /usr/src/tools/tests >> would be the right place. >> >> Any thoughts? >> > Nice hack framework. But looking on subject, my first thought was that > it is something like OpenBSD's vscsi(4). > > nope, but it could be something like it. Look- it's just a really simple junction box to add "soft" hardware to a SIM. I used it to help sort out some race conditions in configuration, and I'm now using it to flesh out the REPORT LUNS implementation. It's a lot quicker to load a kernel module that creates ~10 or so random luns between 0 and 1024 then it is to fart around with various GUIs to set up real (and scarce and hard to share) hardware. In fact, it's even easier to do this than it is to set up target mode, because you can do this on a box that doesn't actually even have any SCSI hardware. From owner-freebsd-scsi@FreeBSD.ORG Sat May 22 04:10: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 1B55F106564A for ; Sat, 22 May 2010 04:10:20 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 05D478FC0A for ; Sat, 22 May 2010 04:10:19 +0000 (UTC) Received: from [127.0.0.1] (proxy10.corp.re1.yahoo.com [69.147.105.206]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4M48vCc032342; Fri, 21 May 2010 21:08:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=JtrdbdK+0WsFhy/tEQk28EGgrWSHFayzt13pOz90x03pGM9cXHWbURjtYgUePHgp From: Sean Bruno To: Matthew Jacob In-Reply-To: <4BF71140.30401@feral.com> References: <4BF70260.7060407@feral.com> <1274480059.2574.11.camel@localhost.localdomain> <4BF71140.30401@feral.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 21 May 2010 21:08:56 -0700 Message-ID: <1274501336.2412.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-scsi@freebsd.org" Subject: Re: vhba/fake hba 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, 22 May 2010 04:10:20 -0000 On Fri, 2010-05-21 at 16:03 -0700, Matthew Jacob wrote: > The latest instantiation can be seen at > http://people.freebsd.org/~mjacob/vhba > > I missed the link to the original source tree you're playing with. > > > > I'd be able to comment more if I knew from whence you're current > > building. > > > > Sean This is actually pretty well suited for src/tools/regressions I can imagine a lot of tests being generated by it. sean