From owner-freebsd-stable@freebsd.org Sun Oct 18 21:21:44 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33A19A18A09 for ; Sun, 18 Oct 2015 21:21:44 +0000 (UTC) (envelope-from lists@searchy.net) Received: from j006.host001.searchy.nl (j006.host001.searchy.nl [79.143.214.199]) by mx1.freebsd.org (Postfix) with ESMTP id BB694872; Sun, 18 Oct 2015 21:21:43 +0000 (UTC) (envelope-from lists@searchy.net) Received: from [192.168.5.21] (5418453B.cm-5-1b.dynamic.ziggo.nl [84.24.69.59]) (Authenticated sender: ppi@j006.host001.searchy.nl) by j006.host001.searchy.nl (Postfix) with ESMTPSA id 4D8D31E8C07; Sun, 18 Oct 2015 21:21:33 +0000 (UTC) Message-ID: <56240D5D.4060205@searchy.net> Date: Sun, 18 Oct 2015 23:21:33 +0200 From: "Frank de Bot (lists)" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 MIME-Version: 1.0 To: FreeBSD Stable , =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= Subject: Re: Reloading iscsi target, iscsi initiator panics References: <561EC629.30106@searchy.net> <20151015113428.GA3741@brick.home> <561FEAF5.8080607@searchy.net> <20151015201212.GA4609@brick.home> <5620A389.5010901@searchy.net> In-Reply-To: <5620A389.5010901@searchy.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 21:21:44 -0000 Frank de Bot wrote: > Edward Tomasz Napierała wrote: >> On 1015T2005, Frank de Bot (lists) wrote: >>> Edward Tomasz Napierała wrote: >>>> On 1014T2316, Frank de Bot (lists) wrote: >>>>> Hello, >>>>> >>>>> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD >>>>> 10.2 is an initiator and has several targets used. >>>>> >>>>> When I add a target and reload its config with 'service ctld reload', >>>>> the FreeBSD initiator server panics. It's reproducable (I have a >>>>> coredump, but I think it's clear what the problem is) >>>> >>>> How easy it is to reproduce, eg. does it happen about every time? >>>> Could you paste the backtrace? >>> >>> The first time I didn't understand what happened, the second time I >>> could relate it directly to the reloading of ctld on the iSCSI, within >>> moments the server paniced. >>> >>> I got 2 backtraces: >>> >>> First one: >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing >> >> This is the FFS on the initiator side panicing because the device it's >> on went away. The softupdates code can't handle that very well. >> >> I have no idea why the devices went away and then reappeared, as visible >> in the logs. What has the changed in the ctl.conf? Do you have any >> iscsi-related sysctls set on the initiator side? >> > > I've added a new target in the ctl.conf . On the linux server I also see > a brief disconnect, but a reconnect is handled well. > > I haven't set any sysctl's related to iscsi > > My ctl.conf is (again anonymized): > > auth-group my-auth { > chap "myiscsi" "verysecret" > } > portal-group pg0 { > discovery-auth-group my-auth > listen 10.13.37.2 > } > > target iqn.2015-03.lan.my.nas:vmstorage-29 { > auth-group my-auth > portal-group pg0 > lun 0 { > path /tank/images/iscsi/vmstorage-29/vmstorage-29.img > size 20484M > blocksize 4096 > option unmap on > } > } > > target iqn.2015-03.lan.my.nas:vmstorage-44 { > auth-group my-auth > portal-group pg0 > lun 0 { > path /tank/images/iscsi/vmstorage-44/vmstorage-44.img > size 102404M > blocksize 4096 > option unmap on > } > } > > target iqn.2015-03.lan.my.nas:keyserver.my.nl { > auth-group my-auth > portal-group pg0 > lun 0 { > path /dev/zvol/tank/hosting_images/keyserver.my.nl > blocksize 4096 > option unmap on > } > } > > the vmstorage-44 is last added to the config > I've started up my test environment, but I could not reproduce is there. When reloading the target, a SCSI sense: UNIT ATTENTION asc:3f,e (Reported LUNs data has changed) is reported, but no device is destroyed. All servers are running the same kernel and userland 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666 What can those device disconnects cause? > > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >