illumos gate

OS: oi_151a

when issuing read commands to a iscsi target on Linux (SCST 2.1.0, scst_cdrom module), I regularly see the connection being dropped by OI:

Mar 25 17:58:10 linuxdev kernel: [0]: iscsi-scst: __iscsi_state_change:444:***ERROR***: Connection with initiator iqn.1986-03.com.sun:01:00900d4901ff.4f62ff12 unexpectedly closed!

After doing a network trace with Wireshark, I noticed that OI indeed closes the socket connection unexpectedly.
I then started investigating the idm module using dtrace, and found that uiomove() returns 14 (EFAULT):

  0  -> idm_fill_iov                          ro 0 dlength 8192
  0  <- idm_fill_iov                          8192
  0  -> idm_iov_sorecv                        so ffffff014d0617a0 iop ffffff014ca086e0 iovlen 1 total_len 8192
  0    -> ksocket_recvmsg                     ks ffffff014d0617a0 msg ffffff0004b5eab0 flags 64 cr ffffff0148468db0
  0      -> socket_recvmsg                    so ffffff014d0617a0 msg ffffff0004b5eab0 uiop ffffff0004b5ea10, cr ffffff0148468db0
  0        -> so_recvmsg                      so ffffff014d0617a0 msg ffffff0004b5eab0 uiop ffffff0004b5ea10, cr ffffff0148468db0
  0          -> so_dequeue_msg                so ffffff014d0617a0
  0            -> uiomove                     p ffffff01562aa0e2 size 1400 uiop ffffff0004b5ea10 resid 8192, uio_segflg 1
  0            <- uiomove                     14 uiop ffffff0004b5ea10 (UIOMOVE ERROR!)
  0          <- socopyoutuio                  0
  0        <- so_dequeue_msg                  14
  0      <- so_recvmsg                        14
  0    <- socket_recvmsg                      14
  0  <- ksocket_recvmsg                       14
  0  <- idm_iov_sorecv                        14
  0  <- idm_sorecvdata                        4
  0  <- idm_sorecv_scsidata                   4
  0  -> idm_conn_event
  0    -> idm_conn_event_handler
  0      -> idm_so_conn_disconnect

The EFAULT error causes a connection failed status in idm, and the socket connection is closed.
The SCSI read command terminates with a transport error.
I can reproduce this very easily. I issue a number of READ commands and run this in a loop.
It always fails on the first uimove in the READ command and the size argument is always 1400 (see above).
However, many READ commands are successful, and they all also start with a 1400 bytes uimove.

I did some further debugging with dtrace and the EFAULT further down occurs in kcopy_nta.

Since I am not a dtrace expert, I would appreciate it if someone could give me some hints on how to investigate
this further.