On Sat, 2012-11-03 at 15:46 +0000, Chris Boot wrote: > Hello again all, > > On 03/11/12 11:37, Chris Boot wrote: > > On 02/11/2012 22:24, Nicholas A. Bellinger wrote: > >> On Fri, 2012-11-02 at 13:58 +0000, Chris Boot wrote: > >>> I have recently acquired a couple of QLE2460 HBAs in order to play > >>> around with the FC target. I have simply strung them together with an > >>> LC-LC fibre pair, and it appears that as soon as I plug the fibre into > >>> both ends the link comes up: I get an entry appearing in > >>> /sys/class/fc_remote_ports/ on both machines that contains correct > >>> information about the node on the other end of the link (WWPNs, > >>> etc...). > >>> > >> You'll want to go ahead and enable ql2xextended_error_logging=0x7fffffff > >> at modprobe time on both sides to understand what's going on. Note this > >> will generate a decent amount of ring buffer output. ;) > > > > I've got a log of the target end with that option set. I've posted it > > here for now, as it's rather too large for email: > > http://www.bootc.net/temp/qla-2012-11-03.log > > > > That's with Windows as an initiator this time. Going into the > > SANsurfer tools it appears that it can see the target end, but it has > > 0 LUNs... > > Well, I'm not sure exactly what I did, but it's working now... > <nod> Looking at qla-2012-11-03.log it appears once the session has been established at: [ 564.731810] qla2xxx [0000:02:00.0]-f84b:8: qla_target(0): session for wwn 21:00:00:1b:32:15:f4:1b (loop_id 0, s_id 0:0:e8, confirmed completion not supported) added that ATIO ring descriptors are being processed (as expected) that contain the incoming SCSI CDBs generated by the initial LUN SCAN, starting with this TEST_UNIT_READY: [ 565.571060] qla2xxx [0000:02:00.0]-e82c:8: qla_target(0): ATIO pkt ffff880400580100: type 06 count 01 [ 565.581615] qla2xxx [0000:02:00.0]-e82d:8: ATIO_TYPE7 instance 0, lun 0, read/write 0/0, add_cdb_len 0, data_length 0000, s_id 0:0:e8 [ 565.625413] qla2xxx [0000:02:00.0]-e822:8: qla_target: START qla command: ffff88032f1edad8 lun: 0x0000 (tag 1131184) [ 565.647967] qla2xxx [0000:02:00.0]-e818:8: is_send_status=1, cmd->bufflen=0, cmd->sg_cnt=0, cmd->dma_data_direction=3 > I basically did a 'make clean' in my kernel tree, and rebuilt with > gcc-4.6 on a whim (Debian default is gcc-4.7, but Debian build their > kernels with 4.6). There was also a 3.2.x kernel update for Debian which > I installed on the initiator, but that's clearly not what made a > difference as the HBA boot code and Windows both work with the target > now. Consider me very confused. > Mmmm, I don't see why gcc would have an effect here. The INQUIRY bug mentioned could be having an effect, as some initiators really don't like getting EVPD=0x83 filled with uninitialized memory.. ;) > Obviously now I'll be doing a bunch more testing, and rebooting my > target and initiator a lot to see if it all breaks again. > Cool. FYI you'll want to also grab v3.6.6 when it comes out to make your target build has the following patches that are now in stable-queue.git: http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=c8292d1da53fa60c7516ab03a9d83f7ea266d335 http://git.kernel.org/?p=linux/kernel/git/nab/target-pending.git;a=commitdiff;h=e13d5fef88c40b87c8430f8274c3a9ca32ef90bc --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
