Peter Dunlap analyzed the trace that Vazer sent and determined the root
cause of the problem. It is being tracked as CR 6867945. Here is a
summary of the analysis:
The attached network trace "mnic_boot" shows a broadcom NIC with iSCSI
offload attempting to boot from a COMSTAR iSCSI lun. Everything works
fine until pkt number 3308 which completes with status "task set
full". This I/O is retried 5 more times and each time fails with
"task set full". Sbd returns "task set full" (a.k.a STATUS_QFULL) in
three places, two of which are because stmf_alloc_dbuf returned NULL.
The third is because TASK_AF_PORT_LOAD_HIGH is set which currently
only happens in fct and is therefore not the culprit.
According to the login PDU (pkt #8), the NIC is negotiating a very
small value for MaxBurstLength (0x2000). Pkt 3308 is attempting a
transfer of 0x2800 bytes which is the first transfer larger than
0x2000. In the iscsit case stmf_alloc_dbuf ends up calling
iscsit_dbuf_alloc which compares the "size" parameter to the
negotiated value for MaxBurstLength. Iscsit catches the fact that
this is larger than MaxBurstLength but it does not take the action
that STMF is expecting.
What iscsit does:
- Set *pminsize to MaxBurstLength, expects STMF to retry allocation
with size=MaxBurstLength
What sbd does:
- Retries stmf_alloc_dbuf with the pminsize value that iscsit set.
Expects iscsit to use min(size, *pminsize) for the buffer.
Since sbd does not do what iscsit is expecting and iscsit does not do
what sbd is expecting, the allocation fails and SBD returns "task set
full".
I'll let the list know when a fix is ready.
Peter C
vazer chan wrote:
Agree on your point.
But in my example, the initiators work mutualy exclusive. So that is not the problem.
The first iqn is when the server is booted with W2K8 and its the iqn of the MS
Software Initiator.
The second initiator is the one in the mNIC iSCSI option ROM and only gets
activated when the server is booted with the mNIC in the first boot order.
Regards,
Vazer
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
