Re: port-sparc64/57785: unable to use iscsi kernel initiator on sparc64

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR port-sparc64/57785; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-sparc64/57785: unable to use iscsi kernel initiator on sparc64
Date: Tue, 19 Dec 2023 09:06:33 -0000 (UTC)

 2857%gmx.de@localhost writes:
 
 >I've setup a 256M test disk:
 >netbsdvm # cat /etc/iscsi/targets
 ># extent        file or device          start           length
 >extent0         /tmp/iscsi-target0      0               256MB
 ># target        flags   storage         netmask
 >target0         rw      extent0         0.0.0.0/0
 
 The userland iscsi-target (and -initiator) are very limited.
 
 
 
 >Kernel log on client after running final newfs command:
 >[ 1655.6300054] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 >[ 1655.7027396] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 >[ 1655.7754745] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 >[ 1655.8482093] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 >[ 1655.9209439] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 >[ 1655.9936783] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 >[ 1656.0664131] sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
 
 Means: the target rejects queries.
 
 
 It does work better against the istgt from pkgsrc.
 
 
 >sunfish # newfs /dev/rsd0
 >newfs: Unable to determine file system size
 
 doesn't really match the disklabel output which returns size information.
 It would be interesting to get output from 'drvctl -p sd0'.
 
 >sunfish # disklabel sd0
 ># /dev/rsd0:
 ...
 >bytes/sector: 512
 ...
 >total sectors: 524288
 ...
 
 >3 partitions:
 >#        size    offset     fstype [fsize bsize cpg/sgs]
 > c:    524288         0     unused      0     0        # (Cyl.      0 -    255)
 
 I get a warning about wrong partition type (not 4.2BSD).
 
 
 >Trying to fix the situation with fdisk:
 sparc64 doesn't regularly MBR partitions but Sun disklabels.
 
 
 I have set up a netbsd-10_RC1/sparc64 system for qemu.
 The target is a netbsd-9/i386 system running istgt.
 
 
 My first problem was that iscsictl login failed with a timeout,
 istgt reported a protocol error. This is because I had configured
 CHAP, which uses "big numbers" that can either be encoded as
 base-64 or as hex strings. The kernel initiator uses base-64
 by default (and accepts anything as answer), but istgt only supports
 hex strings. Setting hw.iscsi.hexbignums=1 with sysctl helps.
 NetBSD-current (and after the latest pullup netbsd-10) switches
 the encoding automatically according to what the target uses.
 
 [  1161.173935] scsibus0 at iscsi0: 1 target, 16 luns per target
 [  1161.193182] sd0 at scsibus0 target 0 lun 0: <NetBSD, iSCSI DISK, 0001> disk fixed
 [  1161.243748] sd0: fabricating a geometry
 [  1161.243748] sd0: 100 GB, 12800 cyl, 64 head, 32 sec, 4096 bytes/sect x 26214400 sectors
 [  1161.253557] sd0: fabricating a geometry
 [  1161.265175] sd0: GPT GUID: ff9d9e75-78aa-4710-adf5-ffd30db38cb3
 [  1161.265175] dk0 at sd0: "links", 26214389 blocks at 6, type: ffs
 [  1161.275293] sd1 at scsibus0 target 0 lun 1: <NetBSD, iSCSI DISK, 0001> disk fixed
 [  1161.323010] sd1: fabricating a geometry
 [  1161.323010] sd1: 100 GB, 12800 cyl, 64 head, 32 sec, 4096 bytes/sect x 26214400 sectors
 [  1161.323010] sd1: fabricating a geometry
 [  1161.334560] sd1: GPT GUID: 6a621763-60e5-44c9-a494-53e27f79308e
 [  1161.334560] dk1 at sd1: "rechts", 26214389 blocks at 6, type: ffs
 [  1161.334560] sd0: async, 8-bit transfers, tagged queueing
 [  1161.334560] sd1: async, 8-bit transfers, tagged queueing
 
 istgt has configured two LUNs for that target. So two disks
 attached.
 
 
 Trying to change the disklabel to 4.2BSD failed with DIOCWDINFO:
 Label magic number or checksum is wrong!.
 This is misleading, the error returned was EINVAL from reading
 the disklabel because I had configured the iscsi volume with
 4K sectors. The sparc64 disklabel routines do not support this.
 
 [  1918.054422] scsibus0 at iscsi0: 1 target, 16 luns per target
 [  1918.073255] sd0 at scsibus0 target 0 lun 0: <NetBSD, iSCSI DISK, 0001> disk fixed
 [  1918.114634] sd0: fabricating a geometry
 [  1918.114634] sd0: 100 GB, 102400 cyl, 64 head, 32 sec, 512 bytes/sect x 209715200 sectors
 [  1918.123510] sd0: fabricating a geometry
 [  1918.133597] sd1 at scsibus0 target 0 lun 1: <NetBSD, iSCSI DISK, 0001> disk fixed
 [  1918.174570] sd1: fabricating a geometry
 [  1918.174570] sd1: 100 GB, 102400 cyl, 64 head, 32 sec, 512 bytes/sect x 209715200 sectors
 [  1918.183509] sd1: fabricating a geometry
 [  1918.183509] sd0: async, 8-bit transfers, tagged queueing
 [  1918.183509] sd1: async, 8-bit transfers, tagged queueing
 
 
 After reconfiguring the target to 512 byte sectors it still
 failed. Despite the error above, disklabel _had_ written
 the new label with the 4096 byte sector size information and
 the system was trusting that information even after the real
 disk had changed. Rewriting the disklabel with the correct
 sector size was then succesful.
 
 # /dev/rsd0:
 type: SCSI
 disk: iSCSI DISK      
 label: fictitious
 flags:
 bytes/sector: 512
 sectors/track: 32
 tracks/cylinder: 64
 sectors/cylinder: 2048
 cylinders: 12800
 total sectors: 26214400
 rpm: 3600
 interleave: 1
 trackskew: 0
 cylinderskew: 0
 headswitch: 0           # microseconds
 track-to-track seek: 0  # microseconds
 drivedata: 0 
 
 3 partitions:
 #        size    offset     fstype [fsize bsize cpg/sgs]
  c:  26214400         0     4.2BSD      0     0     0  # (Cyl.      0 -  12799)
 
 newfs then succeeded and I could mount the volume:
 
 Filesystem     Size   Used  Avail %Cap Mounted on
 /dev/sd0        98G    64M    93G   0% /mnt
 
 N.B. istgt volume definition is now:
 
 [LogicalUnit2]
   Comment "LVM test 1" 
   TargetName test 
   TargetAlias "Test LUN 0"
   Mapping PortalGroup1 InitiatorGroup1
   AuthMethod CHAP
   AuthGroup AuthGroup1
   UseDigest Auto
   UnitType Disk
   QueueDepth 128
   BlockLength 512
   LUN0 Storage /dev/vg0/rlvleft 100GB
   LUN1 Storage /dev/vg0/rlvright 100GB
 
 Backends for the target are two LVM volumes. This (still) requires to
 specify the disk size as istgt tries to query the disk size Linux
 style (with stat()) which does not work reliably for NetBSD device
 nodes.