On Thu, 4 Dec 2008 10:38:53 +0100 Olaf Hering <olh@xxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
