From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 24 16:53:10 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 1686D106566C; Sun, 24 Oct 2010 16:53:10 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C8D938FC19; Sun, 24 Oct 2010 16:53:09 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 328F5E7F6E; Sun, 24 Oct 2010 17:53:09 +0100 (BST) Received: from unknown (client-81-107-142-135.midd.adsl.virginmedia.com [81.107.142.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sun, 24 Oct 2010 17:53:08 +0100 (BST) Date: Sun, 24 Oct 2010 17:53:06 +0100 From: Bruce Cran To: Alexander Motin Message-ID: <20101024175306.00003c66@unknown> In-Reply-To: <4CC4633D.4070605@FreeBSD.org> References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-scsi@freebsd.org, Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 24 Oct 2010 16:53:10 -0000 On Sun, 24 Oct 2010 19:47:57 +0300 Alexander Motin wrote: > Comparing two ways implementing spindown, I've recalled that both of > them using xpt_polled_action() method, which depends on working > controller polling operation. So they could be almost equaly not good. > But the method present in HEAD now is more universal. Looking on fact > that need of spindown is not so obvious for SCSI devices (in SAN > environments), we can just make kern.cam.power_down tunable a bitmask > of supported protocols for now. Patch is attached. I've just committed the patch to move the functionality into ada(4). Should it be reverted? -- Bruce Cran From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 24 17:05:10 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 91099106566B; Sun, 24 Oct 2010 17:05:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF6E8FC13; Sun, 24 Oct 2010 17:05:05 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9OH4jKI052928; Sun, 24 Oct 2010 19:05:01 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9OH4jDM052926; Sun, 24 Oct 2010 19:04:45 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201010241704.o9OH4jDM052926@lurza.secnetix.de> To: bruce@cran.org.uk (Bruce Cran) Date: Sun, 24 Oct 2010 19:04:45 +0200 (CEST) In-Reply-To: <20101024175306.00003c66@unknown> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Sun, 24 Oct 2010 19:05:02 +0200 (CEST) Cc: Alexander Best , Alexander Motin , freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 24 Oct 2010 17:05:10 -0000 Bruce Cran wrote: > I've just committed the patch to move the functionality into ada(4). > Should it be reverted? It seems to me that ATA and SCSI devices are sufficiently different (from the code's point of view) that it makes sense to separate the functionality in the ada and da drivers. In other words, I think the commit is good. I'm biased, though. By the way, I also think it's better to issue a "standby immediate" command, not a "sleep" command. The former is reversible, i.e. the drive can spin up if required (for whatever reason), while the latter may require a hardware reset, according to the documentation. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 24 17:09: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 325E91065670; Sun, 24 Oct 2010 17:09:00 +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 5E3988FC0A; Sun, 24 Oct 2010 17:08:58 +0000 (UTC) Received: by fxm17 with SMTP id 17so2182883fxm.13 for ; Sun, 24 Oct 2010 10:08:58 -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:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=xQ0esLMS5G0mYb3KgJQC7SoYqeHS/WVkxsu2grHnuy4=; b=Ti7fl5BkhbNX9LWAll+wSSFSnPghmt/F851VlimUx3A71zQO9Nm+aIap60rHHpkwNz NeVXI+R12Z0M6W0xF75SunUTIKE/e2oJBUAbTobFTmX670X4WzngM9sCEDa5IrLjCQUU l4XfLi0HjMyYfuEYa5IRy3kMK0KCaM3zcf0sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=k54UzljuhG6v0d4Owruem8LEAuhv0djAGaRnOP6CGUOAu2A7VO2GfHJXDoAAXIG9c4 0Q2Xz3/AhVzakpflEGgHYZLSPLtbjwuIJwQJQlpLkKEIIDPxzecmRr5ri+e+dhlWBGJG OvYWVWS+PRmfLaGf8Bi4iROM79di2oKHpiNvQ= Received: by 10.103.191.17 with SMTP id t17mr6952567mup.54.1287940138250; Sun, 24 Oct 2010 10:08:58 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n8sm2443031faa.31.2010.10.24.10.08.56 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 10:08:57 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC46826.9030700@FreeBSD.org> Date: Sun, 24 Oct 2010 20:08:54 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Bruce Cran References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> <20101024175306.00003c66@unknown> In-Reply-To: <20101024175306.00003c66@unknown> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-scsi@freebsd.org, Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 24 Oct 2010 17:09:00 -0000 Bruce Cran wrote: > On Sun, 24 Oct 2010 19:47:57 +0300 > Alexander Motin wrote: > >> Comparing two ways implementing spindown, I've recalled that both of >> them using xpt_polled_action() method, which depends on working >> controller polling operation. So they could be almost equaly not good. >> But the method present in HEAD now is more universal. Looking on fact >> that need of spindown is not so obvious for SCSI devices (in SAN >> environments), we can just make kern.cam.power_down tunable a bitmask >> of supported protocols for now. Patch is attached. > > I've just committed the patch to move the functionality into ada(4). > Should it be reverted? Both solutions are possible. I don't have strong enough position to hurry now, when it is already done. It would be nice to hear opinion of SCSI people whether this functionality needed/safe there. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 24 17:17:23 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 586BF106566B for ; Sun, 24 Oct 2010 17:17:23 +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 D2EDD8FC20 for ; Sun, 24 Oct 2010 17:17:22 +0000 (UTC) Received: by fxm17 with SMTP id 17so2187275fxm.13 for ; Sun, 24 Oct 2010 10:17:21 -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:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=8HbT/8wjLYDKQ4gbAw/dwjwKz7rZmFdieUsSTG73IpE=; b=w6lXSgoQzN8RkQhyRDVAjJ2QTpb3b+yLgScLUjwONxXXBakfK13UY+6fD3uG32xbg9 JNu9yCCRoq1omFD6n4qEiTqzF3bV1/amQSS+QBQRBbFUdpPkcqMYs4Ue9eplP43IVkrr 8/SzMnrLHcOgyyAmM9SvLt9Gwbc2qnXHc+4TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=nEFAECasUY1fCNa00NmndSuV8QiOCZvCIvovvbJ2hOp2uAFQ5smF1BPZ/lcFbj0/oW YX43BZNSRHBm3G9Ean2fJ+/qrDtE7Za27A6A9mkCbtUo1qM70Ns2EUNnyzxeUiHo12h7 sYcET1xYb6qiGY8PkGQ20iSzNVLFW+bW6DbTw= Received: by 10.102.247.20 with SMTP id u20mr3526997muh.34.1287938881818; Sun, 24 Oct 2010 09:48:01 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id a25sm2437595fab.13.2010.10.24.09.47.59 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 09:48:00 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC4633D.4070605@FreeBSD.org> Date: Sun, 24 Oct 2010 19:47:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> <86zku77mj6.fsf@ds4.des.no> <20101021130730.GA72290@freebsd.org> <86r5fj7gin.fsf@ds4.des.no> <20101024011854.GB78293@freebsd.org> In-Reply-To: <20101024011854.GB78293@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------030609010706040704060309" Cc: freebsd-hackers@freebsd.org, Oliver Fromme , freebsd-scsi@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 24 Oct 2010 17:17:23 -0000 This is a multi-part message in MIME format. --------------030609010706040704060309 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Alexander Best wrote: > On Thu Oct 21 10, Dag-Erling Smørgrav wrote: >> Alexander Best writes: >>> no need to get upset. you asked where i found the information regarding the >>> wear impact of spinning down disks and i gave you the answer. >> I am upset by your claim that "doing spin downs upon reboot might be >> even worse than not doing spindowns upon shutdown", because you should >> know better, and following your advice could damage people's hardware. > > well...since currently hdds don't spindown during shutdown the current behavior > is in fact damaging hardware. i don't quite understand why this hasn't been > fixed yet. the patch is available and known to work. it won't cause any > problems with SCSI devices like mav's current implementation, since the > spindown code is limited to ATA devices. > > instead of talking and talking somebody should drop the changes into HEAD! Comparing two ways implementing spindown, I've recalled that both of them using xpt_polled_action() method, which depends on working controller polling operation. So they could be almost equaly not good. But the method present in HEAD now is more universal. Looking on fact that need of spindown is not so obvious for SCSI devices (in SAN environments), we can just make kern.cam.power_down tunable a bitmask of supported protocols for now. Patch is attached. But there is still question that stops me from going one way or another now. Where all this this things should be done properly: in peripheral driver, as proposed (then it have to be duplicated in da and ada drivers and possibly some others), or at the transport level, as present, independent from drivers? I am not sure, but have feeling that tape drives (for example) may also benefit from head parking before powering down. -- Alexander Motin --------------030609010706040704060309 Content-Type: text/plain; name="spindown3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="spindown3.patch" --- cam_xpt.c.prev 2010-09-22 07:52:38.000000000 +0300 +++ cam_xpt.c 2010-10-24 18:50:13.000000000 +0300 @@ -153,7 +153,7 @@ static struct xpt_softc xsoftc; TUNABLE_INT("kern.cam.boot_delay", &xsoftc.boot_delay); SYSCTL_INT(_kern_cam, OID_AUTO, boot_delay, CTLFLAG_RDTUN, &xsoftc.boot_delay, 0, "Bus registration wait time"); -static int xpt_power_down = 0; +static int xpt_power_down = 1; TUNABLE_INT("kern.cam.power_down", &xpt_power_down); SYSCTL_INT(_kern_cam, OID_AUTO, power_down, CTLFLAG_RW, &xpt_power_down, 0, "Power down devices on shutdown"); @@ -4646,11 +4646,16 @@ xpt_shutdown_dev(struct cam_ed *device, return (1); if (device->protocol == PROTO_ATA) { + if ((xpt_power_down & 1) == 0) + return (1); /* Only power down device if it supports power management. */ if ((device->ident_data.support.command1 & ATA_SUPPORT_POWERMGT) == 0) return (1); - } else if (device->protocol != PROTO_SCSI) + } else if (device->protocol == PROTO_SCSI) { + if ((xpt_power_down & 2) == 0) + return (1); + } else return (1); xpt_compile_path(&path, --------------030609010706040704060309-- From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 24 19:00:55 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 5C17F1065673; Sun, 24 Oct 2010 19:00:55 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id BCA998FC18; Sun, 24 Oct 2010 19:00:54 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFMXxExbsew3/2dsb2JhbACTc41zcroWhUgE Received: from 55.236-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.236.55]) by relay.skynet.be with ESMTP; 24 Oct 2010 20:31:12 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o9OIVBu1081192; Sun, 24 Oct 2010 20:31:12 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-hackers@freebsd.org Date: Sun, 24 Oct 2010 20:30:53 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201009161742.24228.tijl@coosemans.org> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> In-Reply-To: <4CC4633D.4070605@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2379086.db1uFEK4fO"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201010242031.09656.tijl@coosemans.org> Cc: Alexander Best , Alexander Motin , Oliver Fromme , freebsd-scsi@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 24 Oct 2010 19:00:55 -0000 --nextPart2379086.db1uFEK4fO Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sunday 24 October 2010 18:47:57 Alexander Motin wrote: > I am not sure, but have feeling that tape drives (for example) may > also benefit from head parking before powering down. USB hard disks would benefit as well I think. Although, ideally it should happen after unmounting the last file system. --nextPart2379086.db1uFEK4fO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAkzEe2kACgkQfoCS2CCgtiup8QD+PLTzr0ZWOYJrkFU59OENpgu9 iXHRmX9kNlUFCz31agoA/2891eINMM2WO+D7n8g6sohhJjCZvcS9j+tS3y8n1OxY =HQF6 -----END PGP SIGNATURE----- --nextPart2379086.db1uFEK4fO-- From owner-freebsd-scsi@FreeBSD.ORG Sun Oct 24 19:02: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 5F03C1065672; Sun, 24 Oct 2010 19:02:25 +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 8C06D8FC37; Sun, 24 Oct 2010 19:02:24 +0000 (UTC) Received: by fxm17 with SMTP id 17so2245610fxm.13 for ; Sun, 24 Oct 2010 12:02:23 -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:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=t2XK6mZXDm5Wwtz6phu/TV6xl7YIMHCshDJozq0yOWY=; b=npk/1j1cINlkdinZ4sPcaVYz5olBh/Y7jPDIL+z08fAgN8/Axnf3RDztyVAigTxSp5 nOhywIMp0lf051MPeegIRwkpr4vySZV6P7uNsAmuDwvMdIN+lVqJNazwYpkrSrpK0xO/ PVBuSn+0XZUq6BFzdd0CAKzcH0hj64y8MHOEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=uxPtMfZtdv0CvTS1vkPhu9xfF8/lj7L32Xh//bcuBErsplLVFElxw4YUpFboSqDSzA 4rdu45f8uCvUY1CFN/oytqtSpXuw4e7iZHQFl4QlSt5ToVPQWEhsVNdiIDIAXzLAoRca icHmwxVC7vcvSKwiBdj+PcmQ7iNLi2WcWIkcQ= Received: by 10.103.224.5 with SMTP id b5mr5250307mur.58.1287946943213; Sun, 24 Oct 2010 12:02:23 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d20sm1330058fav.14.2010.10.24.12.02.21 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 12:02:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC482BB.90102@FreeBSD.org> Date: Sun, 24 Oct 2010 22:02:19 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Tijl Coosemans References: <201009161742.24228.tijl@coosemans.org> <20101024011854.GB78293@freebsd.org> <4CC4633D.4070605@FreeBSD.org> <201010242031.09656.tijl@coosemans.org> In-Reply-To: <201010242031.09656.tijl@coosemans.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org, Oliver Fromme , Alexander Best Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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, 24 Oct 2010 19:02:25 -0000 Tijl Coosemans wrote: > On Sunday 24 October 2010 18:47:57 Alexander Motin wrote: >> I am not sure, but have feeling that tape drives (for example) may >> also benefit from head parking before powering down. > > USB hard disks would benefit as well I think. Although, ideally it > should happen after unmounting the last file system. Depending on unmount would be excessively aggressive. Far from every device close will be followed by unplugging. Same time nobody denies to run `camcontrol stop daX` before unplugging. USB disks are still "da". It would be more interesting to know if this practice applicable to other kinds of SCSI devices. -- Alexander Motin From owner-freebsd-scsi@FreeBSD.ORG Mon Oct 25 11:07:09 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 06A7010656A4 for ; Mon, 25 Oct 2010 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E79918FC18 for ; Mon, 25 Oct 2010 11:07:08 +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 o9PB783m088880 for ; Mon, 25 Oct 2010 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9PB78kq088878 for freebsd-scsi@FreeBSD.org; Mon, 25 Oct 2010 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Oct 2010 11:07:08 GMT Message-Id: <201010251107.o9PB78kq088878@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, 25 Oct 2010 11:07:09 -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 docs/151336 scsi Missing documentation of scsi_ and ata_ functions in l o kern/149502 scsi [mpt] Latent buglet in debug print code o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/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 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 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 41 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Oct 25 15:55:09 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 634261065670 for ; Mon, 25 Oct 2010 15:55:09 +0000 (UTC) (envelope-from mjohnston@sandvine.com) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id EDDFD8FC1C for ; Mon, 25 Oct 2010 15:55:08 +0000 (UTC) Received: from WTL-EXCH-2.sandvine.com ([fe80::8959:ede3:2dbe:c1b]) by wtl-exch-1.sandvine.com ([fe80::f523:8e57:71d7:5206%14]) with mapi; Mon, 25 Oct 2010 11:55:08 -0400 From: Mark Johnston To: "freebsd-scsi@freebsd.org" Thread-Topic: [Patch] camcontrol - determine the defect list length Thread-Index: Act0XP7EtkzAA2RrQmqTlsb3ojUyrQ== Date: Mon, 25 Oct 2010 15:55:07 +0000 Message-ID: <649630C24D5E884F85DD13645FE903A7640B244F@wtl-exch-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Patch] camcontrol - determine the defect list length 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, 25 Oct 2010 15:55:09 -0000 Hi, Below is a patch for camcontrol from the tree at my work. It was introduced= several years ago to resolve some issues that we were seeing in Adaptec's = RAID controller firmware. The change is to the readdefects() function - whe= n sending the request to read the defect list, instead of using a 65000-ent= ry buffer, we wrote a new function to query the drive and determine the siz= e of the defect list before allocating any memory. Apparently, if we send a= maximum length longer than the number of bytes in the defect list, the cam= call returns an overflow error due to what is probably a firmware bug. It's probable that this issue has been fixed in Adaptec's firmware for a wh= ile now, and that this change is no longer necessary to us. However, it's c= onceivable that other devices could have the same problem, and as far as I = can see, this patch shouldn't introduce any regressions - it essentially co= nsists of sending an additional CAM request before getting the defect list. I'd like to know whether this patch is worth trying to get committed into F= reeBSD. If anyone has some comments or suggestions on the patch, I'd highly= appreciate it. Thanks, -Mark --- camcontrol.c@@/main/RELENG_8/RELENG_8_1/svos_8_1/0 2010-10-21 10:15:24.= 000000000 -0400 +++ camcontrol.c@@/main/RELENG_8/RELENG_8_1/svos_8_1/1 2010-10-21 15:39:04.= 000000000 -0400 @@ -202,6 +202,8 @@ static int scanlun_or_reset_dev(int bus, #ifndef MINIMALISTIC static int readdefects(struct cam_device *device, int argc, char **argv, char *combinedopt, int retry_count, int timeout); +static int readdefectlen(struct cam_device *device, int retry_count,=20 + int timeout, cam_argmask args, int *ret_len); static void modepage(struct cam_device *device, int argc, char **argv, char *combinedopt, int retry_count, int timeout); static int scsicmd(struct cam_device *device, int argc, char **argv,=20 @@ -1722,7 +1724,7 @@ readdefects(struct cam_device *device, i union ccb *ccb =3D NULL; struct scsi_read_defect_data_10 *rdd_cdb; u_int8_t *defect_list =3D NULL; - u_int32_t dlist_length =3D 65000; + u_int32_t dlist_length =3D 0; u_int32_t returned_length =3D 0; u_int32_t num_returned =3D 0; u_int8_t returned_format; @@ -1764,12 +1766,23 @@ readdefects(struct cam_device *device, i =20 ccb =3D cam_getccb(device); =20 - /* - * Hopefully 65000 bytes is enough to hold the defect list. If it - * isn't, the disk is probably dead already. We'd have to go with - * 12 byte command (i.e. alloc_length is 32 bits instead of 16) - * to hold them all. - */ + /* get the defect list length + * We need to do this as a workaround for a bug in either the Adaptec RAI= D or Hitachi scsi + * firmware. For some reason, if we give them a max length greater than t= he number of bytes + * in the dlist + the header length, the cam call returns an overflow err= or. + * It doesn't look like it's in the driver, as this error seems to be pop= ulated by the SRB + * error, and the SRB is an interpreted byte array stored in the FIB, lea= ding me to believe + * that it is directly populated by the firmware. + */ + if((error =3D readdefectlen(device, retry_count, timeout, arglist, &dlist= _length))) + { + warnx("unable to get defect list length"); + goto defect_bailout; + } +=09 + /* the +=3D4 is to hold the header */ + dlist_length +=3D4; +=09 defect_list =3D malloc(dlist_length); if (defect_list =3D=3D NULL) { warnx("can't malloc memory for defect list"); @@ -2004,6 +2017,170 @@ defect_bailout: =20 return(error); } + +/* returns the number of bytes in the appropriate defect list */ +static int readdefectlen(struct cam_device *device, int retry_count,=20 + int timeout, cam_argmask args, int *ret_len) +{ + struct scsi_read_defect_data_10 *rdd_cdb; + u_int8_t *defect_list =3D NULL; + union ccb *ccb =3D NULL; + + u_int8_t returned_format; + /*4 bytes will hold the defect header*/ + u_int32_t dlist_length =3D 4; + u_int32_t returned_length =3D 0; +=09 + int error =3D 0; + int lists_specified =3D 0; + + ccb =3D cam_getccb(device); + + defect_list =3D malloc(dlist_length); + if (defect_list =3D=3D NULL) { + warnx("can't malloc memory for defect list"); + error =3D 1; + goto defect_len_bailout; + } + + rdd_cdb =3D(struct scsi_read_defect_data_10 *)&ccb->csio.cdb_io.cdb_bytes= ; + + /*Essentially just delete stuff from here on*/ + /* + * cam_getccb() zeros the CCB header only. So we need to zero the + * payload portion of the ccb. + */ + bzero(&(&ccb->ccb_h)[1], + sizeof(struct ccb_scsiio) - sizeof(struct ccb_hdr)); + + cam_fill_csio(&ccb->csio, + /*retries*/ retry_count, + /*cbfcnp*/ NULL, + /*flags*/ CAM_DIR_IN | ((arglist & CAM_ARG_ERR_RECOVER) ? + CAM_PASS_ERR_RECOVER : 0), + /*tag_action*/ MSG_SIMPLE_Q_TAG, + /*data_ptr*/ defect_list, + /*dxfer_len*/ dlist_length, + /*sense_len*/ SSD_FULL_SIZE, + /*cdb_len*/ sizeof(struct scsi_read_defect_data_10), + /*timeout*/ timeout ? timeout : 5000); + + rdd_cdb->opcode =3D READ_DEFECT_DATA_10; + if (args & CAM_ARG_FORMAT_BLOCK) + rdd_cdb->format =3D SRDD10_BLOCK_FORMAT; + else if (args & CAM_ARG_FORMAT_BFI) + rdd_cdb->format =3D SRDD10_BYTES_FROM_INDEX_FORMAT; + else if (args & CAM_ARG_FORMAT_PHYS) + rdd_cdb->format =3D SRDD10_PHYSICAL_SECTOR_FORMAT; + else { + error =3D 1; + warnx("no defect list format specified"); + goto defect_len_bailout; + } + if (args & CAM_ARG_PLIST) { + rdd_cdb->format |=3D SRDD10_PLIST; + lists_specified++; + } + + if (args & CAM_ARG_GLIST) { + rdd_cdb->format |=3D SRDD10_GLIST; + lists_specified++; + } + + scsi_ulto2b(dlist_length, rdd_cdb->alloc_length); + + /* Disable freezing the device queue */ + ccb->ccb_h.flags |=3D CAM_DEV_QFRZDIS; + + if (cam_send_ccb(device, ccb) < 0) { + perror("error reading defect list"); + + if (args & CAM_ARG_VERBOSE) { + cam_error_print(device, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + } + + error =3D 1; + goto defect_len_bailout; + } + + returned_length =3D scsi_2btoul(((struct + scsi_read_defect_data_hdr_10 *)defect_list)->length); + + returned_format =3D ((struct scsi_read_defect_data_hdr_10 *) + defect_list)->format; + + if (((ccb->ccb_h.status & CAM_STATUS_MASK) =3D=3D CAM_SCSI_STATUS_ERROR) + && (ccb->csio.scsi_status =3D=3D SCSI_STATUS_CHECK_COND) + && ((ccb->ccb_h.status & CAM_AUTOSNS_VALID) !=3D 0)) { + struct scsi_sense_data *sense; + int error_code, sense_key, asc, ascq; + + sense =3D &ccb->csio.sense_data; + scsi_extract_sense(sense, &error_code, &sense_key, &asc, &ascq); + + /* + * According to the SCSI spec, if the disk doesn't support + * the requested format, it will generally return a sense + * key of RECOVERED ERROR, and an additional sense code + * of "DEFECT LIST NOT FOUND". So, we check for that, and + * also check to make sure that the returned length is + * greater than 0, and then print out whatever format the + * disk gave us. + */ + if ((sense_key =3D=3D SSD_KEY_RECOVERED_ERROR) + && (asc =3D=3D 0x1c) && (ascq =3D=3D 0x00) + && (returned_length > 0)) { + warnx("requested defect format not available"); + switch(returned_format & SRDDH10_DLIST_FORMAT_MASK) { + case SRDD10_BLOCK_FORMAT: + warnx("Device returned block format"); + break; + case SRDD10_BYTES_FROM_INDEX_FORMAT: + warnx("Device returned bytes from index" + " format"); + break; + case SRDD10_PHYSICAL_SECTOR_FORMAT: + warnx("Device returned physical sector format"); + break; + default: + error =3D 1; + warnx("Device returned unknown defect" + " data format %#x", returned_format); + goto defect_len_bailout; + break; /* NOTREACHED */ + } + } else { + error =3D 1; + warnx("Error returned from read defect data command"); + if (args & CAM_ARG_VERBOSE) + cam_error_print(device, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + goto defect_len_bailout; + } + } else if ((ccb->ccb_h.status & CAM_STATUS_MASK) !=3D CAM_REQ_CMP) { + error =3D 1; + warnx("Error returned from read defect data command"); + if (args & CAM_ARG_VERBOSE) + cam_error_print(device, ccb, CAM_ESF_ALL, + CAM_EPF_ALL, stderr); + goto defect_len_bailout; + } + + *ret_len =3D returned_length; + return 0; +defect_len_bailout: + + if (defect_list !=3D NULL) + free(defect_list); + + if (ccb !=3D NULL) + cam_freeccb(ccb); + + return(error); + +} + #endif /* MINIMALISTIC */ =20 #if 0 From owner-freebsd-scsi@FreeBSD.ORG Mon Oct 25 17:29:14 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25DD1065696 for ; Mon, 25 Oct 2010 17:29:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 46D418FC22 for ; Mon, 25 Oct 2010 17:29:13 +0000 (UTC) Received: by ewy28 with SMTP id 28so1704208ewy.13 for ; Mon, 25 Oct 2010 10:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=zRz0vz6QXavLohb3tBiH2UUQRgPQx26pWIcUiHNeDk4=; b=wY7LGl+HBIFj4Fxmzq1Fa2nwPltvWZ/PBS/Bg4AjkY04DxBvXV2A0scyKVDfii3JvM VZOJv8F+QB3KrPDjaKgU82znLZRZQmBzvkhnC+xXDmW0XhPHQth6aNOo/xXDUi5Oo8TZ 0+A/4b7NFHK5+rov9KX5GIaH0VO2WVA2QEPK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uFGF1ZacmMEEH2UMxUeRMs9yMizjqu9EWLs8laZl89+kcqichlfkYLL9IhPBExUitM lCfQtQeWVK7s2/zWKSuev6llDvXflS1gq9Y0XDIElXQK3yGFZXiyzz0C8CJRbttf9cCx Qf8ILxxq6iVY4i1n3+FKAlMShcPuuN5YnCPD4= MIME-Version: 1.0 Received: by 10.213.17.199 with SMTP id t7mr5950679eba.90.1288025988783; Mon, 25 Oct 2010 09:59:48 -0700 (PDT) Received: by 10.213.14.71 with HTTP; Mon, 25 Oct 2010 09:59:48 -0700 (PDT) Date: Mon, 25 Oct 2010 12:59:48 -0400 Message-ID: From: Ryan Stone To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: camcontrol rescan all fails if there is no bus 0 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, 25 Oct 2010 17:29:14 -0000 If you issue a "camcontrol rescan all" on a system that does not have scsi bus 0, camcontrol gets a EINVAL from a CAMIOCOMMAND ioctl and exits after printing an error while trying to do a XPT_DEV_MATCH. This is because camcontrol passes a bzero'd ccb to the ioctl without ever setting the path_id, so CAM looks up path 0 and returns EINVAL if that bus does not exist. This is just slightly annoying if there are no CAM devices on the system. If you had a system with CAM devices, but no bus 0, then camcontrol rescan all would always fail. I'm not sure if it's actually possible to skip path 0, though. The following patch resolves the issue for me: Index: camcontrol.c =================================================================== --- camcontrol.c (revision 214271) +++ camcontrol.c (working copy) @@ -1519,6 +1519,7 @@ rescan_or_reset_bus(int bus, int rescan) bzero(&(&matchccb.ccb_h)[1], sizeof(struct ccb_dev_match) - sizeof(struct ccb_hdr)); matchccb.ccb_h.func_code = XPT_DEV_MATCH; + matchccb.ccb_h.path_id = CAM_BUS_WILDCARD; bufsize = sizeof(struct dev_match_result) * 20; matchccb.cdm.match_buf_len = bufsize; matchccb.cdm.matches=(struct dev_match_result *)malloc(bufsize); (by the way, should I be using CAM_BUS_WILDCARD or CAM_XPT_PATH_ID? By the name WILDCARD seems more appropriate but I see that camcontrol uses CAM_XPT_PATH_ID in getdevtree. From owner-freebsd-scsi@FreeBSD.ORG Mon Oct 25 21:20: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 65536106566B for ; Mon, 25 Oct 2010 21:20:25 +0000 (UTC) (envelope-from bsdboot@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB468FC19 for ; Mon, 25 Oct 2010 21:20:24 +0000 (UTC) Received: by pvc22 with SMTP id 22so616268pvc.13 for ; Mon, 25 Oct 2010 14:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SZ0RQbG3LGUDP5JHThTZJy56atrDBpovSn3NC3M+eV4=; b=mlekXCa3nEWpsjRlQ2+BLPDyx1VfvOK6tCDpS2HHdips5H34/kJP2uu4cQSkJKlW2o q+mZLi0LNihCJcaWgcTPILtaG5LXzjWKAdNyxYZyyvlzVPlCTBXbgQLk+DLOehmnzKg/ Ru7iVK76PRfpfKHBBEI89CuItXCgkcv5ocqz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sIj4NpbGKyLfDOKzJIlhR3cQMvTb9Tbds9y9gUUJJMszP9JrqILFFKNbwlXpgDJufA SXUmzXhd2Itdxt4VTzeu0YuPxMR8it+xGAG1A6Pohfnyw57j8er7rSN8Smt8e4QB6Ygv s3JjodDCdb7lXhlMePBq66lpOUhwd4oI0a1PY= MIME-Version: 1.0 Received: by 10.142.225.19 with SMTP id x19mr5827349wfg.322.1288039847324; Mon, 25 Oct 2010 13:50:47 -0700 (PDT) Received: by 10.143.13.19 with HTTP; Mon, 25 Oct 2010 13:50:47 -0700 (PDT) Date: Tue, 26 Oct 2010 02:20:47 +0530 Message-ID: From: Penta Upa To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems getting target mode to work with isp driver 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, 25 Oct 2010 21:20:25 -0000 Hi, I am having trouble getting target mode to work with isp. The setup is a linux box as the initiator and a FreeBSD 8.1 box as the target. The linux box has a qla2340 card while the target has a qla2342 card both hbas are connected point to point. The target is running a custom build kernel. Kernel configuration is the GENERIC configuration, removing most of the drivers, but i have added the following options relevant to isp > device da 111a117,122 > device targ > device targbh > options CAMDEBUG > options VFS_AIO > options ISP_TARGET_MODE > options ISP_DEFAULT_ROLES=1 isp device hints are as below hint.isp.0.role="target" hint.isp.0.fullduplex="1" To test target mode i ran the following scsi_target 0:0:0 disk.out (i have tried with 0:1:0 also) Once the FreeBSD target is up and running, on the linux side i load the qlogic driver (/sbin/modprobe qla2xxx). The only error message i see on the linux side is something on the lines - command The FreeBSD box was earlier running linux with a target mode driver and the same steps on the initiator used to work fine, so i guess i can rule out an issue with the HBA hardware. I later reinstalled the box with the 8.1 release. I have changed the cabling a few times to rule out any faulty cables. Below are relevant syslog messages Linux ------ Oct 26 01:09:20 scache2 kernel: QLogic Fibre Channel HBA Driver: 8.02.00-k5-rhel5.2-04 Oct 26 01:09:20 scache2 kernel: QLogic QLA2342 - 133MHz PCI-X to 2Gb FC, Dual Channel Oct 26 01:09:20 scache2 kernel: ISP2312: PCI-X (133 MHz) @ 0000:06:01.1 hdma-, host#=17, fw=3.03.26 IPX Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LIP occured (f7f7). Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LOOP UP detected (2 Gbps). Oct 26 01:09:43 scache2 kernel: scsi 17:0:0:0: timing out command, waited 22s FreeBSD ------- isp0: port 0x2000-0x20ff mem 0x81a00000-0x81a00fff irq 32 at device 2.0 on pci2 Oct 25 19:38:32 scache kernel: isp0: [ITHREAD] Oct 25 19:41:09 scache kernel: isp0: target notify code 0x100b Is there anything i'm missing here. Kindly help. Regards, Penta From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 05:22: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 2B26E106564A for ; Tue, 26 Oct 2010 05:22:14 +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 CBDF08FC13 for ; Tue, 26 Oct 2010 05:22:13 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9Q5M9k4007968; Mon, 25 Oct 2010 23:22:09 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <649630C24D5E884F85DD13645FE903A7640B244F@wtl-exch-2.sandvine.com> Date: Mon, 25 Oct 2010 23:22:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <649630C24D5E884F85DD13645FE903A7640B244F@wtl-exch-2.sandvine.com> To: Mark Johnston X-Mailer: Apple Mail (2.1081) 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: [Patch] camcontrol - determine the defect list length 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, 26 Oct 2010 05:22:14 -0000 On Oct 25, 2010, at 9:55 AM, Mark Johnston wrote: > Hi, >=20 > Below is a patch for camcontrol from the tree at my work. It was = introduced several years ago to resolve some issues that we were seeing = in Adaptec's RAID controller firmware. The change is to the = readdefects() function - when sending the request to read the defect = list, instead of using a 65000-entry buffer, we wrote a new function to = query the drive and determine the size of the defect list before = allocating any memory. Apparently, if we send a maximum length longer = than the number of bytes in the defect list, the cam call returns an = overflow error due to what is probably a firmware bug. >=20 > It's probable that this issue has been fixed in Adaptec's firmware for = a while now, and that this change is no longer necessary to us. However, = it's conceivable that other devices could have the same problem, and as = far as I can see, this patch shouldn't introduce any regressions - it = essentially consists of sending an additional CAM request before getting = the defect list. >=20 > I'd like to know whether this patch is worth trying to get committed = into FreeBSD. If anyone has some comments or suggestions on the patch, = I'd highly appreciate it. >=20 Should the whole operation of reading the defect list abort if = readdefectlen() fails, or should it just fall back to a modest length = and try the operation anyways? Also, if readdefectlen() succeeds, how = do the defect_list and ccb get freed? Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 14:40:59 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 547AA106564A for ; Tue, 26 Oct 2010 14:40:59 +0000 (UTC) (envelope-from mjohnston@sandvine.com) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id E8A3B8FC0A for ; Tue, 26 Oct 2010 14:40:58 +0000 (UTC) Received: from WTL-EXCH-1.sandvine.com ([fe80::f523:8e57:71d7:5206]) by wtl-exch-2.sandvine.com ([fe80::8959:ede3:2dbe:c1b%15]) with mapi; Tue, 26 Oct 2010 10:40:58 -0400 From: Mark Johnston To: Scott Long Thread-Topic: [Patch] camcontrol - determine the defect list length Thread-Index: Act0XP7EtkzAA2RrQmqTlsb3ojUyrQAkkTSAAAnNEZA= Date: Tue, 26 Oct 2010 14:40:57 +0000 Message-ID: <649630C24D5E884F85DD13645FE903A7640B50C2@wtl-exch-1.sandvine.com> References: <649630C24D5E884F85DD13645FE903A7640B244F@wtl-exch-2.sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" Subject: RE: [Patch] camcontrol - determine the defect list length 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, 26 Oct 2010 14:40:59 -0000 >> Hi, >>=20 >> Below is a patch for camcontrol from the tree at my work. It was introdu= ced several years ago to resolve some issues that we were seeing in Adaptec= 's RAID controller firmware. The change is to the readdefects() function - = when sending the request to read the defect list, instead of using a 65000-= entry buffer, we wrote a new function to query the drive and determine the = size of the defect list before allocating any memory. Apparently, if we sen= d a maximum length longer than the number of bytes in the defect list, the = cam call returns an overflow error due to what is probably a firmware bug. >>=20 >> It's probable that this issue has been fixed in Adaptec's firmware for a= while now, and that this change is no longer necessary to us. However, it'= s conceivable that other devices could have the same problem, and as far as= I can see, this patch shouldn't introduce any regressions - it essentially= consists of sending an additional CAM request before getting the defect li= st. >>=20 >> I'd like to know whether this patch is worth trying to get committed int= o FreeBSD. If anyone has some comments or suggestions on the patch, I'd hig= hly appreciate it. >>=20 > Should the whole operation of reading the defect list abort if readdefect= len() fails, or should it just fall back to a modest length and try the ope= ration anyways? > Also, if readdefectlen() succeeds, how do the defect_lis= t and ccb get freed? > Scott Ah, thanks for pointing that out. The patch below fixes the missing frees. I would argue that there's not much point in retrying the operation if read= defectlen() fails since readdefectlen() performs essentially the same operations as readdefects() -= readdefectlen() will fail if: 1. malloc() returns NULL somewhere, 2. the defect list format isn't specified 3. cam_send_ccb() fails 4. the request defect list format isn't supported 5. there was an error when reading the defect list data Of these, I don't see any reason that readdefects() would succeed if readde= fectlen() fails. cam_send_ccb() performs a cam ioctl which in turn fails if functions like xpt_find_bus() a= nd xpt_find_target() do. It doesn't seem likely to me that a second call would succeed if the first failed. Thanks, -Mark --- camcontrol.c@@/main/RELENG_8/RELENG_8_1/svos_8_1/1 2010-10-21 15:39:04= .000000000 -0400 +++ camcontrol.c 2010-10-26 10:12:12.000000000 -0400 @@ -2168,7 +2168,7 @@ static int readdefectlen(struct cam_devi } =20 *ret_len =3D returned_length; - return 0; + defect_len_bailout: =20 if (defect_list !=3D NULL) From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 15:55:28 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 E064B1065781 for ; Tue, 26 Oct 2010 15:55:28 +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 857438FC1A for ; Tue, 26 Oct 2010 15:55:28 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9QFtPiF011720; Tue, 26 Oct 2010 09:55:25 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Tue, 26 Oct 2010 09:55:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Stone X-Mailer: Apple Mail (2.1081) 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: camcontrol rescan all fails if there is no bus 0 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, 26 Oct 2010 15:55:29 -0000 On Oct 25, 2010, at 10:59 AM, Ryan Stone wrote: > If you issue a "camcontrol rescan all" on a system that does not have > scsi bus 0, camcontrol gets a EINVAL from a CAMIOCOMMAND ioctl and > exits after printing an error while trying to do a XPT_DEV_MATCH. > This is because camcontrol passes a bzero'd ccb to the ioctl without > ever setting the path_id, so CAM looks up path 0 and returns EINVAL if > that bus does not exist. >=20 > This is just slightly annoying if there are no CAM devices on the > system. If you had a system with CAM devices, but no bus 0, then > camcontrol rescan all would always fail. I'm not sure if it's > actually possible to skip path 0, though. >=20 > The following patch resolves the issue for me: > Index: camcontrol.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- camcontrol.c (revision 214271) > +++ camcontrol.c (working copy) > @@ -1519,6 +1519,7 @@ rescan_or_reset_bus(int bus, int rescan) > bzero(&(&matchccb.ccb_h)[1], > sizeof(struct ccb_dev_match) - sizeof(struct ccb_hdr)); > matchccb.ccb_h.func_code =3D XPT_DEV_MATCH; > + matchccb.ccb_h.path_id =3D CAM_BUS_WILDCARD; > bufsize =3D sizeof(struct dev_match_result) * 20; > matchccb.cdm.match_buf_len =3D bufsize; > matchccb.cdm.matches=3D(struct dev_match_result = *)malloc(bufsize); >=20 >=20 > (by the way, should I be using CAM_BUS_WILDCARD or CAM_XPT_PATH_ID? > By the name WILDCARD seems more appropriate but I see that camcontrol > uses CAM_XPT_PATH_ID in getdevtree. It appears unfortunate that CAM_XPT_PATH_ID and CAM_BUS_WILDCARD = evaluate to the same value. CAM_XPT_PATH_ID is supposed to be specific = to the pseudo bus that is owned by the XPT module, so I don't know why = it is this way. I'd suggest to use CAM_BUS_WILDCARD here in case = CAM_XPT_PATH_ID changes in the future. That being said, there's a comment block right above the code that you = changed that suggests that the XPT pseudo-bus handler won't behave = correctly if it gets a rescan or reset command, hinting that that's why = the enumeration starts specifically a '0' instead of 'CAM_BUS_WILDCARD'. = Did you see any evidence of this in your testing? Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 16:04:58 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 9134F10656A3 for ; Tue, 26 Oct 2010 16:04:58 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 52D4D8FC1B for ; Tue, 26 Oct 2010 16:04:58 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Tue, 26 Oct 2010 12:04:57 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 610E533C00; Tue, 26 Oct 2010 12:04:57 -0400 (EDT) Date: Tue, 26 Oct 2010 12:04:57 -0400 From: Ed Maste To: Scott Long Message-ID: <20101026160457.GA61133@sandvine.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 26 Oct 2010 16:04:58 -0000 On Tue, Oct 26, 2010 at 09:55:24AM -0600, Scott Long wrote: > On Oct 25, 2010, at 10:59 AM, Ryan Stone wrote: > > > ... > > Index: camcontrol.c > > =================================================================== > > --- camcontrol.c (revision 214271) > > +++ camcontrol.c (working copy) > > @@ -1519,6 +1519,7 @@ rescan_or_reset_bus(int bus, int rescan) > > bzero(&(&matchccb.ccb_h)[1], > > sizeof(struct ccb_dev_match) - sizeof(struct ccb_hdr)); > > matchccb.ccb_h.func_code = XPT_DEV_MATCH; > > + matchccb.ccb_h.path_id = CAM_BUS_WILDCARD; > > bufsize = sizeof(struct dev_match_result) * 20; > > matchccb.cdm.match_buf_len = bufsize; > > matchccb.cdm.matches=(struct dev_match_result *)malloc(bufsize); > > ... > ... > That being said, there's a comment block right above the code that you changed that suggests that the XPT pseudo-bus handler won't behave correctly if it gets a rescan or reset command, hinting that that's why the enumeration starts specifically a '0' instead of 'CAM_BUS_WILDCARD'. Did you see any evidence of this in your testing? That's this comment block I presume: /* * The right way to handle this is to modify the xpt so that it can * handle a wildcarded bus in a rescan or reset CCB. At the moment * that isn't implemented, so instead we enumerate the busses and * send the rescan or reset to those busses in the case where the * given bus is -1 (wildcard). We don't send a rescan or reset * to the xpt bus; sending a rescan to the xpt bus is effectively a * no-op, sending a rescan to the xpt bus would result in a status of * CAM_REQ_INVALID. */ I think it's still true; Ryan's change uses CAM_BUS_WILDCARD for the XPT_DEV_MATCH ioctl in order to enumerate the busses, and the path_id that gets used for the actual rescan or reset should be that returned from the match should it not? -Ed From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 16:41:15 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 60473106566B for ; Tue, 26 Oct 2010 16:41:15 +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 F0EA48FC1B for ; Tue, 26 Oct 2010 16:41:14 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9QGfBCJ011987; Tue, 26 Oct 2010 10:41:11 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20101026160457.GA61133@sandvine.com> Date: Tue, 26 Oct 2010 10:41:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> References: <20101026160457.GA61133@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, MIME_QP_LONG_LINE, 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: camcontrol rescan all fails if there is no bus 0 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, 26 Oct 2010 16:41:15 -0000 On Oct 26, 2010, at 10:04 AM, Ed Maste wrote: > On Tue, Oct 26, 2010 at 09:55:24AM -0600, Scott Long wrote: >=20 >> On Oct 25, 2010, at 10:59 AM, Ryan Stone wrote: >>=20 >>> ... >>> Index: camcontrol.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- camcontrol.c (revision 214271) >>> +++ camcontrol.c (working copy) >>> @@ -1519,6 +1519,7 @@ rescan_or_reset_bus(int bus, int rescan) >>> bzero(&(&matchccb.ccb_h)[1], >>> sizeof(struct ccb_dev_match) - sizeof(struct ccb_hdr)); >>> matchccb.ccb_h.func_code =3D XPT_DEV_MATCH; >>> + matchccb.ccb_h.path_id =3D CAM_BUS_WILDCARD; >>> bufsize =3D sizeof(struct dev_match_result) * 20; >>> matchccb.cdm.match_buf_len =3D bufsize; >>> matchccb.cdm.matches=3D(struct dev_match_result = *)malloc(bufsize); >>> ... >> ... >> That being said, there's a comment block right above the code that = you changed that suggests that the XPT pseudo-bus handler won't behave = correctly if it gets a rescan or reset command, hinting that that's why = the enumeration starts specifically a '0' instead of 'CAM_BUS_WILDCARD'. = Did you see any evidence of this in your testing? >=20 > That's this comment block I presume: >=20 > /* > * The right way to handle this is to modify the xpt so that it can > * handle a wildcarded bus in a rescan or reset CCB. At the moment > * that isn't implemented, so instead we enumerate the busses and > * send the rescan or reset to those busses in the case where the > * given bus is -1 (wildcard). We don't send a rescan or reset > * to the xpt bus; sending a rescan to the xpt bus is effectively a > * no-op, sending a rescan to the xpt bus would result in a status of > * CAM_REQ_INVALID. > */ >=20 > I think it's still true; Ryan's change uses CAM_BUS_WILDCARD for the > XPT_DEV_MATCH ioctl in order to enumerate the busses, and the path_id > that gets used for the actual rescan or reset should be that returned > from the match should it not? >=20 > -Ed Ok, I guess I need to see if CAM_XPT_PATH_ID can get returned from the = devmatch. What happens with this patch if you run it with no real buses = registered (i.e. cam module present, but no SIMs present)? Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 16:46: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 6A035106567A for ; Tue, 26 Oct 2010 16:46:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AF9948FC08 for ; Tue, 26 Oct 2010 16:46:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA02925; Tue, 26 Oct 2010 19:46:00 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CC705C8.9050604@icyb.net.ua> Date: Tue, 26 Oct 2010 19:46:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Ryan Stone References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 26 Oct 2010 16:46:04 -0000 on 25/10/2010 19:59 Ryan Stone said the following: > If you issue a "camcontrol rescan all" on a system that does not have > scsi bus 0, camcontrol gets a EINVAL from a CAMIOCOMMAND ioctl and > exits after printing an error while trying to do a XPT_DEV_MATCH. > This is because camcontrol passes a bzero'd ccb to the ioctl without > ever setting the path_id, so CAM looks up path 0 and returns EINVAL if > that bus does not exist. > > This is just slightly annoying if there are no CAM devices on the > system. If you had a system with CAM devices, but no bus 0, then > camcontrol rescan all would always fail. I'm not sure if it's > actually possible to skip path 0, though. Oh, I remember this issue: http://thread.gmane.org/gmane.os.freebsd.devel.scsi/4405 > The following patch resolves the issue for me: > Index: camcontrol.c > =================================================================== > --- camcontrol.c (revision 214271) > +++ camcontrol.c (working copy) > @@ -1519,6 +1519,7 @@ rescan_or_reset_bus(int bus, int rescan) > bzero(&(&matchccb.ccb_h)[1], > sizeof(struct ccb_dev_match) - sizeof(struct ccb_hdr)); > matchccb.ccb_h.func_code = XPT_DEV_MATCH; > + matchccb.ccb_h.path_id = CAM_BUS_WILDCARD; > bufsize = sizeof(struct dev_match_result) * 20; > matchccb.cdm.match_buf_len = bufsize; > matchccb.cdm.matches=(struct dev_match_result *)malloc(bufsize); > > > (by the way, should I be using CAM_BUS_WILDCARD or CAM_XPT_PATH_ID? > By the name WILDCARD seems more appropriate but I see that camcontrol > uses CAM_XPT_PATH_ID in getdevtree. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 17:14: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 BE4C31065672; Tue, 26 Oct 2010 17:14:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25EA28FC0C; Tue, 26 Oct 2010 17:14:37 +0000 (UTC) Received: by ewy28 with SMTP id 28so2428395ewy.13 for ; Tue, 26 Oct 2010 10:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sWGrW4oYJZonXEghSh78GhewJakzAfOpri7LFj4gO4M=; b=v8GMDAEaetB159XFSoft/1EOwS0SbRWz1aDuDkPhVi71RCoENG3b4mCn1+EXflYpos quJmFzGYHNoLhSY7V0+OYDO+68aJe9r8lzf2TG6p6hPezo1fwsXXXWg/Y2Qy2gIS/PWt y2gpoLENz8SO+VaznwDkIhxg4GRS9YHEhqp0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RZAlRxQC8EnFC7DFmkSmoE2CD2KfTmqvMtQtckXHY0n8r3lOJviY/CTG9fTZ9UJ/eW voFb/DdGnIwnsEAttTtvVAE9mnB9Gck47u9XBTb0VFYcepO4XfM1KnDvDR+r2SbosU+m n1XkGxr0lL3H2oHwh2uSjOOZJL7n4VRIxAMQ0= MIME-Version: 1.0 Received: by 10.213.14.79 with SMTP id f15mr7297645eba.58.1288113276807; Tue, 26 Oct 2010 10:14:36 -0700 (PDT) Received: by 10.213.14.71 with HTTP; Tue, 26 Oct 2010 10:14:36 -0700 (PDT) In-Reply-To: <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> References: <20101026160457.GA61133@sandvine.com> <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> Date: Tue, 26 Oct 2010 13:14:36 -0400 Message-ID: From: Ryan Stone To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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, 26 Oct 2010 17:14:38 -0000 On Tue, Oct 26, 2010 at 12:41 PM, Scott Long wrote: > Ok, I guess I need to see if CAM_XPT_PATH_ID can get returned from the devmatch. There is some really awful code to deal with that later on: /* * We don't want to rescan or reset the xpt bus. * See above. */ if ((int)bus_result->path_id == -1) continue; That should be changed to use the real constants. > What happens with this patch if you run it with no real buses registered (i.e. cam module present, but no SIMs present)? If there are no CAM devices(i.e. "camcontrol devlist" prints nothing) as near as I can tell with my patch a "camcontrol rescan all" does nothing(camcontrol prints "Rescanning bus X" for each bus that it rescans, and camcontrol rescan all prints nothing if there are no buses at all). From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 23:09: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 25650106564A for ; Tue, 26 Oct 2010 23:09: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 D21E38FC13 for ; Tue, 26 Oct 2010 23:09: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 o9QN9e7i093787 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 26 Oct 2010 16:09:44 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CC75FAE.9060708@feral.com> Date: Tue, 26 Oct 2010 16:09:34 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: 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.6 (ns1.feral.com [192.168.221.1]); Tue, 26 Oct 2010 16:09:44 -0700 (PDT) Subject: Re: Problems getting target mode to work with isp driver 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, 26 Oct 2010 23:09:45 -0000 To a first approximation, it worked for me on a 24XX: localhost.localdomain > lsscsi [4:0:0:0] disk SEAGATE ST314655SSUN146G 0791 /dev/sda [4:0:1:0] disk ATA ST3500630NS G /dev/sdb [4:0:2:0] disk ATA ST3500630NS G /dev/sdc [4:0:3:0] disk ATA Maxtor 7Y250M0 1EW0 /dev/sdd [4:0:4:0] disk ATA ST3500630NS G /dev/sde [4:0:5:0] disk ATA ST3500630NS G /dev/sdf [4:0:6:0] enclosu ESG-SHV. SCA HSBP M1..... 2.09 - [6:0:0:0] disk FreeBSD Emulated Disk 0.1 /dev/sdg It's entirely 23XX is broken. I'll see if I can hook one up and let you know. On 10/25/2010 1:50 PM, Penta Upa wrote: > Hi, > > I am having trouble getting target mode to work with isp. The setup is a > linux box as the initiator and a FreeBSD 8.1 box as the target. The linux > box has a qla2340 card while the target has a qla2342 card both hbas are > connected point to point. > > The target is running a custom build kernel. Kernel configuration is the > GENERIC configuration, removing most of the drivers, but i have added the > following options relevant to isp > >> device da > 111a117,122 >> device targ >> device targbh >> options CAMDEBUG >> options VFS_AIO >> options ISP_TARGET_MODE >> options ISP_DEFAULT_ROLES=1 > isp device hints are as below > hint.isp.0.role="target" > hint.isp.0.fullduplex="1" > > To test target mode i ran the following > scsi_target 0:0:0 disk.out (i have tried with 0:1:0 also) > > Once the FreeBSD target is up and running, on the linux side i load the > qlogic driver (/sbin/modprobe qla2xxx). The only error message i see on the > linux side is something on the lines - command > > The FreeBSD box was earlier running linux with a target mode driver and the > same steps on the initiator used to work fine, so i guess i can rule out an > issue with the HBA hardware. I later reinstalled the box with the 8.1 > release. I have changed the cabling a few times to rule out any faulty > cables. > > Below are relevant syslog messages > > Linux > ------ > Oct 26 01:09:20 scache2 kernel: QLogic Fibre Channel HBA Driver: > 8.02.00-k5-rhel5.2-04 > Oct 26 01:09:20 scache2 kernel: QLogic QLA2342 - 133MHz PCI-X to 2Gb FC, > Dual Channel > Oct 26 01:09:20 scache2 kernel: ISP2312: PCI-X (133 MHz) @ 0000:06:01.1 > hdma-, host#=17, fw=3.03.26 IPX > Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LIP occured (f7f7). > Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LOOP UP detected (2 > Gbps). > Oct 26 01:09:43 scache2 kernel: scsi 17:0:0:0: timing out command, waited > 22s > > FreeBSD > ------- > isp0: port 0x2000-0x20ff mem > 0x81a00000-0x81a00fff irq 32 at device 2.0 on pci2 > Oct 25 19:38:32 scache kernel: isp0: [ITHREAD] > Oct 25 19:41:09 scache kernel: isp0: target notify code 0x100b > > Is there anything i'm missing here. Kindly help. > > Regards, > Penta > _______________________________________________ > 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 Wed Oct 27 02:02:28 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 C4104106564A for ; Wed, 27 Oct 2010 02:02:28 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id 944928FC08 for ; Wed, 27 Oct 2010 02:02:28 +0000 (UTC) Received: from c-71-194-154-137.hsd1.in.comcast.net (c-71-194-154-137.hsd1.in.comcast.net [71.194.154.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id A6A0D1B082 for ; Wed, 27 Oct 2010 01:33:46 +0000 (GMT) Date: Tue, 26 Oct 2010 21:33:41 -0400 (EDT) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: freebsd-scsi@freebsd.org In-Reply-To: <649630C24D5E884F85DD13645FE903A7640B244F@wtl-exch-2.sandvine.com> Message-ID: <20101025120535.W1326@familysquires.net> References: <649630C24D5E884F85DD13645FE903A7640B244F@wtl-exch-2.sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Tyan S4881/SCSI/FreeBSD 7.x 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, 27 Oct 2010 02:02:28 -0000 Is anyone out there using a Tyan S4881 (quad Opteron with 2 PCI-Express slots, not the S4882 with only PCI-X and PCI slots)? I have a system running 7.3-STABLE (see below) with an LSI 300-8X (PCI-X with 8 750GB Seagate ES drives) but I'm unable to add a SCSI controller to any slot. Any attempt to add a SCSI card gets the following error (example is with an LSI 53C1010-66 66Mhz PCI-X in a slot set at 66MHz by jumper). I've tried a PCI-E card (PERC4e/DC BIOS H430, configures correctly) with the same error but different device (OE) number. I don't see anything obvious in the BIOS configuration pages> I did see one error message (since lost) that indicated the PCI-X slot was hardwired to an IRQ that did not match the one selected by the SCSI card, but there is no obvious way to change either IRQ. BIOS error message: System Configuration Data updated ERROR Warning: IRQ not configured - PCI Mass Storage Controller in slot 03 Bus:11, Device:03, Function:00 LSI 53C1010-66 (I also have two systems with S4882 boards, no such problems; I'm about to replace the S4881 with a spare S4882). dmesg: FreeBSD 7.3-STABLE #10: Fri Sep 24 14:46:43 EDT 2010 root@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 875 (2210.20-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f10 Family = f Model = 21 Stepping = 0 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 usable memory = 18492895232 (17636 MB) avail memory = 17794420736 (16970 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs dmesg output for sym0 controller (tape drive, Overland library with two Sony AIT-3 drives, is not found: sym0: <1010-66> port 0x3000-0x30ff mem 0xd0142000-0xd01423ff,0xd0140000-0xd0141f ff at device 3.0 on pci17 sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym0: [ITHREAD] (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. From owner-freebsd-scsi@FreeBSD.ORG Wed Oct 27 04:33:09 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 960021065672 for ; Wed, 27 Oct 2010 04:33:09 +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 613CB8FC0C for ; Wed, 27 Oct 2010 04:33:09 +0000 (UTC) Received: from [172.16.135.100] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9R4X86k095264 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 26 Oct 2010 21:33:08 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CC7AB7E.3050705@feral.com> Date: Tue, 26 Oct 2010 21:33:02 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4CC75FAE.9060708@feral.com> In-Reply-To: <4CC75FAE.9060708@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Tue, 26 Oct 2010 21:33:08 -0700 (PDT) Subject: Re: Problems getting target mode to work with isp driver 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, 27 Oct 2010 04:33:09 -0000 Worked with a 2300 as well on a fabric. Guess I'd better try point to point. On 10/26/2010 4:09 PM, Matthew Jacob wrote: > To a first approximation, it worked for me on a 24XX: > > localhost.localdomain > lsscsi > [4:0:0:0] disk SEAGATE ST314655SSUN146G 0791 /dev/sda > [4:0:1:0] disk ATA ST3500630NS G /dev/sdb > [4:0:2:0] disk ATA ST3500630NS G /dev/sdc > [4:0:3:0] disk ATA Maxtor 7Y250M0 1EW0 /dev/sdd > [4:0:4:0] disk ATA ST3500630NS G /dev/sde > [4:0:5:0] disk ATA ST3500630NS G /dev/sdf > [4:0:6:0] enclosu ESG-SHV. SCA HSBP M1..... 2.09 - > [6:0:0:0] disk FreeBSD Emulated Disk 0.1 /dev/sdg > > > It's entirely 23XX is broken. I'll see if I can hook one up and let > you know. > > > On 10/25/2010 1:50 PM, Penta Upa wrote: >> Hi, >> >> I am having trouble getting target mode to work with isp. The setup is a >> linux box as the initiator and a FreeBSD 8.1 box as the target. The >> linux >> box has a qla2340 card while the target has a qla2342 card both hbas are >> connected point to point. >> >> The target is running a custom build kernel. Kernel configuration is the >> GENERIC configuration, removing most of the drivers, but i have added >> the >> following options relevant to isp >> >>> device da >> 111a117,122 >>> device targ >>> device targbh >>> options CAMDEBUG >>> options VFS_AIO >>> options ISP_TARGET_MODE >>> options ISP_DEFAULT_ROLES=1 >> isp device hints are as below >> hint.isp.0.role="target" >> hint.isp.0.fullduplex="1" >> >> To test target mode i ran the following >> scsi_target 0:0:0 disk.out (i have tried with 0:1:0 also) >> >> Once the FreeBSD target is up and running, on the linux side i load the >> qlogic driver (/sbin/modprobe qla2xxx). The only error message i see >> on the >> linux side is something on the lines - command >> >> The FreeBSD box was earlier running linux with a target mode driver >> and the >> same steps on the initiator used to work fine, so i guess i can rule >> out an >> issue with the HBA hardware. I later reinstalled the box with the 8.1 >> release. I have changed the cabling a few times to rule out any faulty >> cables. >> >> Below are relevant syslog messages >> >> Linux >> ------ >> Oct 26 01:09:20 scache2 kernel: QLogic Fibre Channel HBA Driver: >> 8.02.00-k5-rhel5.2-04 >> Oct 26 01:09:20 scache2 kernel: QLogic QLA2342 - 133MHz PCI-X to >> 2Gb FC, >> Dual Channel >> Oct 26 01:09:20 scache2 kernel: ISP2312: PCI-X (133 MHz) @ >> 0000:06:01.1 >> hdma-, host#=17, fw=3.03.26 IPX >> Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LIP occured >> (f7f7). >> Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LOOP UP >> detected (2 >> Gbps). >> Oct 26 01:09:43 scache2 kernel: scsi 17:0:0:0: timing out command, >> waited >> 22s >> >> FreeBSD >> ------- >> isp0: port 0x2000-0x20ff mem >> 0x81a00000-0x81a00fff irq 32 at device 2.0 on pci2 >> Oct 25 19:38:32 scache kernel: isp0: [ITHREAD] >> Oct 25 19:41:09 scache kernel: isp0: target notify code 0x100b >> >> Is there anything i'm missing here. Kindly help. >> >> Regards, >> Penta >> _______________________________________________ >> 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" > _______________________________________________ > 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 Wed Oct 27 17:16: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 8F8E3106566B for ; Wed, 27 Oct 2010 17:16:02 +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 00A878FC1C for ; Wed, 27 Oct 2010 17:16: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 o9RHFux4056397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Oct 2010 10:16:00 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CC85E46.10209@feral.com> Date: Wed, 27 Oct 2010 10:15:50 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 27 Oct 2010 10:16:01 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fwd: Fwd: sg3_utils, sdparm and ddpt 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, 27 Oct 2010 17:16:02 -0000 -------- Original Message -------- Subject: Fwd: sg3_utils, sdparm and ddpt Date: Wed, 27 Oct 2010 10:49:46 -0400 From: Douglas Gilbert Reply-To: dgilbert@interlog.com To: Matthew Jacob Matthew, I tried to post the following to the freebsd-scsi list a week ago. The response said it was going to be moderated but it has not turned up on the list yet. Could you help to get it posted? Doug Gilbert -------- Original Message -------- Subject: sg3_utils, sdparm and ddpt Date: Tue, 19 Oct 2010 12:45:47 +0200 From: Douglas Gilbert Reply-To: dgilbert@interlog.com To: freebsd-scsi@freebsd.org I maintain various SCSI related tools whose native platform is Linux. These three packages have ports (i.e. tarballs) that build on FreeBSD: sg3_utils: http://sg.danny.cz/sg/sg3_utils.html sdparm: http://sg.danny.cz/sg/sdparm.html ddpt: http://sg.danny.cz/sg/ddpt.html ddpt was released recently and adds SCSI pass-through support and other extensions to the standard dd command. In Linux the SCSI pass-through can be applied to (S)ATA disks since recent Linux kernels "hide" most ATA devices behind a SAT layer. When I tested on a FreeBSD 8.0 release there was no SAT layer in front of ATA devices making ddpt's pass-through less useful. As an example ddpt can be used to "trim" all or part of a SSD in Linux. Even though most SSDs on the market have a SATA interface, ddpt can issue a SCSI WRITE SAME command (with the UNMAP bit set) which the Linux SAT layer translates into a ATA DATA SET MANAGEMENT command (with the TRIM bit set). Doug Gilbert From owner-freebsd-scsi@FreeBSD.ORG Wed Oct 27 20:20: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 E1F7B106564A for ; Wed, 27 Oct 2010 20:20:14 +0000 (UTC) (envelope-from bsdboot@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98E738FC0C for ; Wed, 27 Oct 2010 20:20:14 +0000 (UTC) Received: by gxk9 with SMTP id 9so789850gxk.13 for ; Wed, 27 Oct 2010 13:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5nt24XtT3ExI1LfovEyI5AVJ6USulM/Wnjpz6zaZK5s=; b=GxR7rtAL99OqUI5n2zTNOnsda4QSVjawedN2iYd0NutbuM8LhDSZrF/xGJM0D6TFRl 22dndVsP82F5SrdIRNS8uC3OFpBRZb9fcfvtPZRSMTi5q9JdDJKeEKatFAvuWjNiHQN2 RIGOhlXIGtvDr5naNsCDcsQiid89XkvbfMcEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j/ownZEax9ErwdWLZmOfoBRs1cXvCPtlFdqwpCvp7SeJOr/u2FydjeXIyFdCRIsVlS SnQwEsB0o0oUnXSm1V/loTWYL++DvQTaNB2hTs897VsLwA6DEMyyxQaET0KUjPOmi/Vw Cww8AzzYIuMasGoJcFYCCz9+wT0nHU1EmmsPk= MIME-Version: 1.0 Received: by 10.42.214.80 with SMTP id gz16mr7581761icb.502.1288210813508; Wed, 27 Oct 2010 13:20:13 -0700 (PDT) Received: by 10.231.153.13 with HTTP; Wed, 27 Oct 2010 13:20:13 -0700 (PDT) In-Reply-To: <4CC7AB7E.3050705@feral.com> References: <4CC75FAE.9060708@feral.com> <4CC7AB7E.3050705@feral.com> Date: Thu, 28 Oct 2010 01:50:13 +0530 Message-ID: From: Penta Upa To: Matthew Jacob Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Problems getting target mode to work with isp driver 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, 27 Oct 2010 20:20:15 -0000 Hi Matthew, I changed the setup to use a solaris initiator and it worked fine then. The solaris m/c is a different box with a 2340 card. I guess the linux box is the culprit. I assume that it it isn't an issue with linux os (RHEL 5.2) as it had been used as an initiator many times before and no changes were made to that system. Could it be that after all its a HBA issue or a cabling issue ? I'll try to move the HBA from the linux box to the solaris box and try to confirm that. Thanks, Penta On Wed, Oct 27, 2010 at 10:03 AM, Matthew Jacob wrote: > Worked with a 2300 as well on a fabric. > Guess I'd better try point to point. > > > On 10/26/2010 4:09 PM, Matthew Jacob wrote: > >> To a first approximation, it worked for me on a 24XX: >> >> localhost.localdomain > lsscsi >> [4:0:0:0] disk SEAGATE ST314655SSUN146G 0791 /dev/sda >> [4:0:1:0] disk ATA ST3500630NS G /dev/sdb >> [4:0:2:0] disk ATA ST3500630NS G /dev/sdc >> [4:0:3:0] disk ATA Maxtor 7Y250M0 1EW0 /dev/sdd >> [4:0:4:0] disk ATA ST3500630NS G /dev/sde >> [4:0:5:0] disk ATA ST3500630NS G /dev/sdf >> [4:0:6:0] enclosu ESG-SHV. SCA HSBP M1..... 2.09 - >> [6:0:0:0] disk FreeBSD Emulated Disk 0.1 /dev/sdg >> >> >> It's entirely 23XX is broken. I'll see if I can hook one up and let you >> know. >> >> >> On 10/25/2010 1:50 PM, Penta Upa wrote: >> >>> Hi, >>> >>> I am having trouble getting target mode to work with isp. The setup is a >>> linux box as the initiator and a FreeBSD 8.1 box as the target. The linux >>> box has a qla2340 card while the target has a qla2342 card both hbas are >>> connected point to point. >>> >>> The target is running a custom build kernel. Kernel configuration is the >>> GENERIC configuration, removing most of the drivers, but i have added the >>> following options relevant to isp >>> >>> device da >>>> >>> 111a117,122 >>> >>>> device targ >>>> device targbh >>>> options CAMDEBUG >>>> options VFS_AIO >>>> options ISP_TARGET_MODE >>>> options ISP_DEFAULT_ROLES=1 >>>> >>> isp device hints are as below >>> hint.isp.0.role="target" >>> hint.isp.0.fullduplex="1" >>> >>> To test target mode i ran the following >>> scsi_target 0:0:0 disk.out (i have tried with 0:1:0 also) >>> >>> Once the FreeBSD target is up and running, on the linux side i load the >>> qlogic driver (/sbin/modprobe qla2xxx). The only error message i see on >>> the >>> linux side is something on the lines - command >>> >>> The FreeBSD box was earlier running linux with a target mode driver and >>> the >>> same steps on the initiator used to work fine, so i guess i can rule out >>> an >>> issue with the HBA hardware. I later reinstalled the box with the 8.1 >>> release. I have changed the cabling a few times to rule out any faulty >>> cables. >>> >>> Below are relevant syslog messages >>> >>> Linux >>> ------ >>> Oct 26 01:09:20 scache2 kernel: QLogic Fibre Channel HBA Driver: >>> 8.02.00-k5-rhel5.2-04 >>> Oct 26 01:09:20 scache2 kernel: QLogic QLA2342 - 133MHz PCI-X to 2Gb >>> FC, >>> Dual Channel >>> Oct 26 01:09:20 scache2 kernel: ISP2312: PCI-X (133 MHz) @ 0000:06:01.1 >>> hdma-, host#=17, fw=3.03.26 IPX >>> Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LIP occured (f7f7). >>> Oct 26 01:09:21 scache2 kernel: qla2xxx 0000:06:01.1: LOOP UP detected (2 >>> Gbps). >>> Oct 26 01:09:43 scache2 kernel: scsi 17:0:0:0: timing out command, waited >>> 22s >>> >>> FreeBSD >>> ------- >>> isp0: port 0x2000-0x20ff mem >>> 0x81a00000-0x81a00fff irq 32 at device 2.0 on pci2 >>> Oct 25 19:38:32 scache kernel: isp0: [ITHREAD] >>> Oct 25 19:41:09 scache kernel: isp0: target notify code 0x100b >>> >>> Is there anything i'm missing here. Kindly help. >>> >>> Regards, >>> Penta >>> _______________________________________________ >>> 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" >>> >> _______________________________________________ >> 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" >> > _______________________________________________ > 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 Wed Oct 27 23:31: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 D5C8E1065693 for ; Wed, 27 Oct 2010 23:31: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 9FD738FC13 for ; Wed, 27 Oct 2010 23:31:00 +0000 (UTC) Received: from [172.16.135.100] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9RNUxS8062739 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 16:30:59 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CC8B62E.1090506@feral.com> Date: Wed, 27 Oct 2010 16:30:54 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Penta Upa References: <4CC75FAE.9060708@feral.com> <4CC7AB7E.3050705@feral.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 27 Oct 2010 16:30:59 -0700 (PDT) Cc: freebsd-scsi@freebsd.org Subject: Re: Problems getting target mode to work with isp driver 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, 27 Oct 2010 23:31:00 -0000 Since this was all point to point, my guess is that it's a soft loop id issue. You can try your original setup again (linux to FreeBSD), but for the FreeBSD box add this to loader.conf: set hint.isp.0.iid=75 From owner-freebsd-scsi@FreeBSD.ORG Thu Oct 28 20:22:33 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826A91065675 for ; Thu, 28 Oct 2010 20:22:33 +0000 (UTC) (envelope-from bsdboot@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 529F18FC17 for ; Thu, 28 Oct 2010 20:22:33 +0000 (UTC) Received: by pwi8 with SMTP id 8so276222pwi.13 for ; Thu, 28 Oct 2010 13:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P3RoTSRBrtKzcDnkNqMzjIrOpEfA2A5pQ1BXBw2c2DE=; b=HEyHlWXrw5oqyeJv7wWJzLkUuK+8bG5eEzXD9cKlTogB7HJqfDA6NzITRUHRDSQzxA lSh5dKRWDRcHgrMK34Hol5OiR5p1QHvCvI2no5Ywias/k647bw3AH7CWIrtofpguexlk V8IYxB4rAFFOdiQxvY+IgG7VDnXh0UCiAuLgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vChmvRk/3AzME3sm/MOpLlpR6gw0BChShZ7f7bDp0cML4b29E6WBmCOA/ciWPH/hJV dvxNblDcoeEr+pkuVfAYgAqjZ117Kt2z2ceS3B38vOfpwAPcdmGitU8TwmLVbvbWhEnv 2ckKUDGAIDSMpMxHWWKg2zK9bcBJcjHOrsbZA= MIME-Version: 1.0 Received: by 10.142.238.9 with SMTP id l9mr652876wfh.213.1288297352774; Thu, 28 Oct 2010 13:22:32 -0700 (PDT) Received: by 10.143.13.19 with HTTP; Thu, 28 Oct 2010 13:22:32 -0700 (PDT) In-Reply-To: <4CC8B62E.1090506@feral.com> References: <4CC75FAE.9060708@feral.com> <4CC7AB7E.3050705@feral.com> <4CC8B62E.1090506@feral.com> Date: Fri, 29 Oct 2010 01:52:32 +0530 Message-ID: From: Penta Upa To: Matthew Jacob Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Problems getting target mode to work with isp driver 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, 28 Oct 2010 20:22:33 -0000 On Thu, Oct 28, 2010 at 5:00 AM, Matthew Jacob wrote: > Since this was all point to point, my guess is that it's a soft loop id > issue. > > You can try your original setup again (linux to FreeBSD), but for the > FreeBSD box add this to loader.conf: > > set hint.isp.0.iid=75 > > target mode doesn't work by setting the above hint in the loader.conf. (even with the solaris box) The earlier linux setup doesn't work. I also tried with another linux box (RHEL 5.5) which had both qla2340 and qla2460 cards and with windows 2003 (which is the same as the solaris box). But they dont work with or without the hint. Once i removed the hint from the loader.conf, solaris works but not linux or windows I'll attach the the initiators and target to a switch over the weekend and narrow it down to a point to point issue. Thanks a lot for the help and many apologies for the delay in response. I'm trying out target mode as a personal project which i do after work. Thanks, Penta From owner-freebsd-scsi@FreeBSD.ORG Fri Oct 29 19:46:40 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1AF1065670; Fri, 29 Oct 2010 19:46:40 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D8A978FC08; Fri, 29 Oct 2010 19:46:39 +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 o9TJkdix020919; Fri, 29 Oct 2010 19:46:39 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9TJkdwT020915; Fri, 29 Oct 2010 19:46:39 GMT (envelope-from arundel) Date: Fri, 29 Oct 2010 19:46:39 GMT Message-Id: <201010291946.o9TJkdwT020915@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/57088: [cam] [patch] for a possible fd leak in libcam.c 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, 29 Oct 2010 19:46:40 -0000 Synopsis: [cam] [patch] for a possible fd leak in libcam.c Responsible-Changed-From-To: freebsd-fs->freebsd-scsi Responsible-Changed-By: arundel Responsible-Changed-When: Fri Oct 29 19:44:28 UTC 2010 Responsible-Changed-Why: Freebsd-scsi@ seems better suited for this PR than freebsd-fs@. Thanks to Jaakko Heinonen for pointing this out. ;) http://www.freebsd.org/cgi/query-pr.cgi?pr=57088