Hi Jeff, On Thu, 2013-03-21 at 14:48 -0700, Jeff Leung wrote: > Sorry for the noise, but I've probably run into a regression where when I > attempt to validate a Microsoft failover cluster with an iSCSI target host > running kernel 3.8.3. > > Microsoft's failover cluster validation tests returns the following error > when it attempts to pass the "SCSI-3 Persistent Reservation" test: > > Success returned calling Persistent Reservation PREEMPT by node > HVCLUSTER2.smb.curriegrad2004.ca which was not registered on Test Disk 0 > which was currently reserved by node HVCLUSTER1.smb.curriegrad2004.ca. It is > expected to fail. > Thanks for the detailed bug description. > When I perform a dmesg I see the following kernel messages: > > [ 379.846756] SPC-3 PR: Attempted RESERVE from [iSCSI]: > iqn.1991-05.com.microsoft:hvcluster1.smb.curriegrad2004.ca while reservation > already held by [iSCSI]: > iqn.1991-05.com.microsoft:hvcluster2.smb.curriegrad2004.ca, returning > RESERVATION_CONFLICT > [ 379.878579] SPC-3 PR: Attempted RESERVE from [iSCSI]: > iqn.1991-05.com.microsoft:hvcluster1.smb.curriegrad2004.ca while reservation > already held by [iSCSI]: > iqn.1991-05.com.microsoft:hvcluster2.smb.curriegrad2004.ca, returning > RESERVATION_CONFLICT > [ 380.921863] SPC-3 PR: Unable to locate PR_REGISTERED *pr_reg for RELEASE > [ 380.928377] SPC-3 PR: Unable to locate PR_REGISTERED *pr_reg for RELEASE > [ 380.974719] SPC-3 PR: Unable to locate PR_REGISTERED *pr_reg for RELEASE > [ 380.985632] SPC-3 PR: Unable to locate PR_REGISTERED *pr_reg for RELEASE > [ 381.481037] SPC-3 PR: Unable to locate PR_REGISTERED *pr_reg for RELEASE > [ 381.989328] SPC-3 PR: Unable to locate PR_REGISTERED *pr_reg for RELEASE > Mmmm, strangely enough there is not a PR-OUT PREEMPT operation message in this output to match the specific failure case mentioned above.. I'll try reproducing with PR-OUT PREEMPT on my side, but also posting a wire-shark capture to verify this output against would be very helpful. > To verify that it may be a regression, I've compiled the 3.2 kernel from > Ubuntu's git and re-validated the cluster. That kernel validated just fine. > Btw, thanks for testing with v3.2 to verify that things are working as expected. So starting with v3.8-rc1 code, there where two PR related changes that went into mainline: target: pass sense_reason as a return value http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/drivers/target/target_core_pr.c?id=de103c93aff0bed0ae984274e5dc8b95899badab target: simplify reservations code http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/drivers/target/target_core_pr.c?id=d977f4377fbc396b888e12fdb3b13118b09ca7db It also would be helpful on your end to verify using v3.7.10 to isolate the culprit down to pre or post v3.8.x code. Thank you! --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
