From owner-freebsd-scsi@freebsd.org Wed Jan 16 09:05:56 2019 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 960BA14A74E7 for ; Wed, 16 Jan 2019 09:05:56 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5CDA92D33 for ; Wed, 16 Jan 2019 09:05:54 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.134] (helo=smtp10.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1gjh8r-0006V1-7Z for freebsd-scsi@freebsd.org; Wed, 16 Jan 2019 10:05:45 +0100 Received: from 5ed231fb.cm-7-3a.dynamic.ziggo.nl ([94.210.49.251] helo=wan0.bsd4all.org) by smtp10.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1gjh8r-0005Oo-4u for freebsd-scsi@freebsd.org; Wed, 16 Jan 2019 10:05:45 +0100 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id AF617FA for ; Wed, 16 Jan 2019 10:05:44 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF9bt7OnZdWA for ; Wed, 16 Jan 2019 10:05:44 +0100 (CET) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 3214DEF for ; Wed, 16 Jan 2019 10:05:44 +0100 (CET) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: iSCSI stall Message-Id: <3579EC93-825D-4908-B177-673363111BEF@bsd4all.org> Date: Wed, 16 Jan 2019 10:05:43 +0100 To: freebsd-scsi@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-SourceIP: 94.210.49.251 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=aPGOVo1m c=1 sm=1 tr=0 a=7fK1ynn72W3Z/oi6DA4Tww==:17 a=IkcTkHD0fZMA:10 a=3JhidrIBZZsA:10 a=X-ym7V0z0cYcq1pNt-kA:9 a=QEXdDO2ut3YA:10 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Rspamd-Queue-Id: E5CDA92D33 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of peter.blok@bsd4all.org designates 212.54.42.168 as permitted sender) smtp.mailfrom=peter.blok@bsd4all.org X-Spamd-Result: default: False [-1.54 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; NEURAL_HAM_MEDIUM(-0.65)[-0.650,0]; MIME_TRACE(0.00)[0:+]; R_SPF_ALLOW(-0.20)[+a:smtp.ziggo.nl/16]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-scsi@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.90)[-0.898,0]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[smtp.bsd4all.org]; NEURAL_HAM_SHORT(-0.09)[-0.088,0]; FROM_NO_DN(0.00)[]; IP_SCORE(0.00)[country: NL(0.02)]; DMARC_NA(0.00)[bsd4all.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[168.42.54.212.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[251.49.210.94.zen.spamhaus.org : 127.0.0.11] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 09:05:56 -0000 Hi, I have a ReadyNAS RND4000 as an iSCSI target. The target is the only = device in a ZFS pool and is receiving backups thru zfs receive. The = initiator is FreeBSD 11.x (recent stable at this moment), but this = probably happens with 12.0 as well. During a zfs receive it stalls. Nothing happens anymore. When I send a = TUR via camcontrol everything continues. Any other target on any other = platform works fine. When I take a network trace it looks as if it is around SYNCHRONIZE = CACHE. If this takes too long in the target and before the reply is back = some new READ CDBs are send, it seems to hang only showing Nop-In and = Nop-out. The moment I send a TUR it continues replying with the data of = the READs that were owed. It is not a big deal, but it irritates me and I would like to create a = work-around for this, assuming it is caused by the target and there is = probably no way to fix it there. One test was to create a quirk to = reduce the tags to 1, but that didn=E2=80=99t help. Although it is 1 it = still seems to send multiple CDB concurrently. In the past I have attempted to port FreeBSD to the ReadyNAS, but got = stuck on fan control. I wasn=E2=80=99t able to control the fan and it = made too much noise. I was able to get the network up and running. Any tips?