EDN Admin
Well-known member
Hi,
I am communicating with my SAS Expander using DeviceIOControl (along with CreateFile) using IOCTL_SCSI_PASS_THROUGH in a user mode application. Everything has worked fine for months, many, many months now without a hitch and being used daily, until
a couple days ago. Now, I get a failure in DeviceIOControl. CreateFile is fine. I obtain a handle to the RAID HBA using a symbolic link that I query from an enumeration (SetupDI*).
<pre class="prettyprint ScsiPassThroughWithBuffers sptwb = new ScsiPassThroughWithBuffers();
sptwb.Init();
// Create Command: Inquiry
CreateCmdInquiry(ref sptwb);
uint inBufferSize = (uint)Marshal.SizeOf(typeof(ScsiPassThroughWithBuffers));
uint iSizeBasic = (uint)Marshal.SizeOf(typeof(ScsiPassThrough));
uint bytesReturned = 0;
Boolean bResult = DeviceIoControl(this.DevHandle, EIOControlCode.IOCTL_SCSI_PASS_THROUGH, (object)sptwb, inBufferSize, (object)sptwb, inBufferSize, ref bytesReturned, IntPtr.Zero);
if (false == bResult)
String strMsg = String.Format("DeviceIOControl ERROR: {0} {1}", Marshal.GetLastWin32Error().ToString("x"), new Win32Exception().Message);
[/code]
Here are the values of the buffer going in.
sptwb<br/>
Data byte[512]<br/>
Sense byte[32]<br/>
Spt<br/>
Cdb byte[16]<br/>
CdbLength 16<br/>
DataBufferOffset 76<br/>
DataIn 1<br/>
DataTransferLength 512<br/>
Length 44<br/>
Lun 0<br/>
pathId 0<br/>
ScsiStatus 0<br/>
SenseInfoLength 32<br/>
SenseInfoOffset 44<br/>
TargetId 0<br/>
TimeOutValue 10<br/>
I suspect that the cause of the problem may be the fact that I pulled an ATTO R348 card and replaced it with an ATTO R680 card. The card swap might be a coincidence or part of the cause. I merely mention the fact. Everything worked
fine up until I put in the ATTO R680 card. The code pulls the symbolic link for whichever card my software finds that it knows about.
In order to debug the problem, I uninstalled with deleting the driver the ATTO R680 and (and ATTO R348). I replaced the ATTO R348 card and installed the driver anew. After multiple required reboots, I wind up with the same problem. The
R680 card also throws the same error code.
My current thought is that possibly I need to specify a non-zero TargetId, PathId, and/or Lun. Maybe I just got lucky in the past. I do not wish to talk to any hard drive, just the expander.
I hooked up a SAS Analyzer and there are no messages (sent or received) going across the line as a result of the DeviceIOControl call. I should add here that the system (ATTO Configuration Utility) sees the expander and its accompanying hard drives
fine. The notification service also sees the attached box nicely too.
For whatever it is worth, here is the CreateFile section. CreateFile succeeds. The handle definitely talks to the HBA.
<pre class="prettyprint this.DevHandle = CreateFile(this.DOSName, FileAccess.ReadWrite, FileShare.ReadWrite, IntPtr.Zero, FileMode.Open, FileAttributes.Normal, IntPtr.Zero);[/code]
Oh yes, I checked the details of the failure and there is no inner exception or source, so nothing more to go on.
My thought again is that maybe I just got lucky in the past and the TargetId (or whatever) was zero and I passed zero. Maybe the problem is somewhere else.
The only other thing to note is that the error is consistent. Also, a Google search (and Bing search) yielded nothing useful and very few failures on DeviceIOControl.
Thanks,
Sarah Weinberger
View the full article
I am communicating with my SAS Expander using DeviceIOControl (along with CreateFile) using IOCTL_SCSI_PASS_THROUGH in a user mode application. Everything has worked fine for months, many, many months now without a hitch and being used daily, until
a couple days ago. Now, I get a failure in DeviceIOControl. CreateFile is fine. I obtain a handle to the RAID HBA using a symbolic link that I query from an enumeration (SetupDI*).
<pre class="prettyprint ScsiPassThroughWithBuffers sptwb = new ScsiPassThroughWithBuffers();
sptwb.Init();
// Create Command: Inquiry
CreateCmdInquiry(ref sptwb);
uint inBufferSize = (uint)Marshal.SizeOf(typeof(ScsiPassThroughWithBuffers));
uint iSizeBasic = (uint)Marshal.SizeOf(typeof(ScsiPassThrough));
uint bytesReturned = 0;
Boolean bResult = DeviceIoControl(this.DevHandle, EIOControlCode.IOCTL_SCSI_PASS_THROUGH, (object)sptwb, inBufferSize, (object)sptwb, inBufferSize, ref bytesReturned, IntPtr.Zero);
if (false == bResult)
String strMsg = String.Format("DeviceIOControl ERROR: {0} {1}", Marshal.GetLastWin32Error().ToString("x"), new Win32Exception().Message);
[/code]
Here are the values of the buffer going in.
sptwb<br/>
Data byte[512]<br/>
Sense byte[32]<br/>
Spt<br/>
Cdb byte[16]<br/>
CdbLength 16<br/>
DataBufferOffset 76<br/>
DataIn 1<br/>
DataTransferLength 512<br/>
Length 44<br/>
Lun 0<br/>
pathId 0<br/>
ScsiStatus 0<br/>
SenseInfoLength 32<br/>
SenseInfoOffset 44<br/>
TargetId 0<br/>
TimeOutValue 10<br/>
I suspect that the cause of the problem may be the fact that I pulled an ATTO R348 card and replaced it with an ATTO R680 card. The card swap might be a coincidence or part of the cause. I merely mention the fact. Everything worked
fine up until I put in the ATTO R680 card. The code pulls the symbolic link for whichever card my software finds that it knows about.
In order to debug the problem, I uninstalled with deleting the driver the ATTO R680 and (and ATTO R348). I replaced the ATTO R348 card and installed the driver anew. After multiple required reboots, I wind up with the same problem. The
R680 card also throws the same error code.
My current thought is that possibly I need to specify a non-zero TargetId, PathId, and/or Lun. Maybe I just got lucky in the past. I do not wish to talk to any hard drive, just the expander.
I hooked up a SAS Analyzer and there are no messages (sent or received) going across the line as a result of the DeviceIOControl call. I should add here that the system (ATTO Configuration Utility) sees the expander and its accompanying hard drives
fine. The notification service also sees the attached box nicely too.
For whatever it is worth, here is the CreateFile section. CreateFile succeeds. The handle definitely talks to the HBA.
<pre class="prettyprint this.DevHandle = CreateFile(this.DOSName, FileAccess.ReadWrite, FileShare.ReadWrite, IntPtr.Zero, FileMode.Open, FileAttributes.Normal, IntPtr.Zero);[/code]
Oh yes, I checked the details of the failure and there is no inner exception or source, so nothing more to go on.
My thought again is that maybe I just got lucky in the past and the TargetId (or whatever) was zero and I passed zero. Maybe the problem is somewhere else.
The only other thing to note is that the error is consistent. Also, a Google search (and Bing search) yielded nothing useful and very few failures on DeviceIOControl.
Thanks,
Sarah Weinberger
View the full article