[stgt] state of ibmvio

[FUJITA Tomonori]

On Thu, 4 Dec 2008 10:38:53 +0100
Olaf Hering <olh at suse.de> wrote:

> 
> What is the state of the ibmvio target? 
> When did it work, does anyone still successfully use it?

It worked. But seems that I broke user-space code. I've applied some
fixes to the git tree. You need the latest user-space git tree:

tgtadm: restore tgtadm bind option with bus  master
author	FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp>
	Thu, 4 Dec 2008 10:13:26 +0000 (19:13 +0900)


Now I can boot the client:

scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
ibmvscsi 30000002: partner initialization complete
ibmvscsi 30000002: sent SRP login
ibmvscsi 30000002: SRP_LOGIN succeeded
ibmvscsi 30000002: host srp version: 16.a, host partition LINUX VIO (2), OS 2, max io 131072
scsi 0:0:0:0: RAID              IBM      VOPTA blkdev     0001 PQ: 0 ANSI: 4
scsi 0:0:1:0: Direct-Access     IBM      VDASD blkdev     0001 PQ: 0 ANSI: 4
sd 0:0:1:0: [sda] 29298688 512-byte hardware sectors (15001 MB)
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 79 00 00 08
sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:1:0: [sda] 29298688 512-byte hardware sectors (15001 MB)
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 79 00 00 08
sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA


> Right now my first tests with it are unsuccessful.
> 
> ...
> running with firmware 'IBM,SF235_214' on model 'IBM,9133-55A', serial 'IBM,0210C3E0D', partition 'vioserver'
> ...
> 
> + tgtadm --lld ibmvio --mode target --op new --tid 1 --targetname pear_vioclient1_1
> + tgtadm --lld ibmvio --mode logicalunit --op new --tid 1 --lun 1 -b /dev/disk/by-id/scsi-35000cca001c3fcf6-part1
> + tgtadm --lld ibmvio --mode target --op bind --tid 1 --bus vio,30000003

Are you sure '30000003' is appropriate for your system? I just asked
because it's used in the example of README.

> ...
> Dec  4 10:27:33 pear kernel: scsi_tgt_uspace_send_cmd(128) tx buf is full, could not send
> Dec  4 10:27:33 pear kernel: handle_cmd_queue(211) cannot queue cmd c0000001db4a0000 -4
> Dec  4 10:27:33 pear kernel: klogd 1.4.1, ---------- state change ----------
> Dec  4 10:27:39 pear kernel: scsi_tgt_uspace_send_tsk_mgmt(175) tx buf is full, could not send
> Dec  4 10:27:39 pear kernel: scsi_tgt_tsk_mgmt_request(540) The task management request lost!
> Dec  4 10:27:49 pear kernel: scsi_tgt_uspace_send_tsk_mgmt(175) tx buf is full, could not send
> Dec  4 10:27:49 pear kernel: scsi_tgt_tsk_mgmt_request(540) The task management request lost!
> Dec  4 10:27:59 pear kernel: process_iu(529) -11 transferring data error c0000001db6995e0
> Dec  4 10:28:09 pear kernel: scsi_tgt_uspace_send_cmd(128) tx buf is full, could not send
> Dec  4 10:28:09 pear kernel: handle_cmd_queue(211) cannot queue cmd c0000001db630000 -4
> Dec  4 10:28:39 pear kernel: scsi_tgt_uspace_send_tsk_mgmt(175) tx buf is full, could not send
> Dec  4 10:28:39 pear kernel: scsi_tgt_tsk_mgmt_request(540) The task management request lost!
> Dec  4 10:28:49 pear kernel: scsi_tgt_uspace_send_tsk_mgmt(175) tx buf is full, could not send
> Dec  4 10:28:49 pear kernel: scsi_tgt_tsk_mgmt_request(540) The task management request lost!
> ...
> 
> 
> On the client side, there is a 2.6.16 or 2.6.27 kernel.

Hmm, somehow the kernel can't send messages to user-space daemon
(tgtd). tgtd is dead, wrong configuration, or some other reasons.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html