On 1018T2321, Frank de Bot (lists) wrote:
> 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?
Well, that's the thing: ctld was written to make really, really sure
that reloading configuration does not affect LUNs and targets which
hadn't changed. So, to be honest - no idea. Are you sure you didn't
restart (as in, stop and then start again) ctld instead of reloading
its configuration?
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
