Hi guys,
This issue was posted a couple of times here about a month ago (see message
from David Wang 5/5/2004) but, unfortunately, I did not see any reply with
solution
When we run HCT test for our SCSI miniport driver, we have a data read
error (“Data read is not what that was expected” log message) after system
wake up from S4 in ACPI S1 Stress.
We found out that, the test ACPI S1 Stress failed any time when Force IRQL
checking and DMA checking options are enabled in Driver Verifier.
If I disable ScatterGather in SCSI miniport or make a DMA read transfer to
buffer allocated as SRB extension, the test also passes OK.
We are using Windows XP SP1 OS
Thank you in advance
Stanislav Samsonov
Things to make sure of:
-
You’re getting the physical address of the buffer using
ScsiPortGetPhysicalAddress and not by calling MmGetPhysicalAddress - the
latter won’t account for DMA remapping and you will get an incorrect
result when DMA checking is enabled.
-
Make sure you’re updating DataTransferLength in the SRB correctly
after a transfer occurs.
Beyond that you probably need to watch the IO requests and see what’s
wrong with the data being returned - that may help you diagnose the
problem.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Stanislav
Samsonov
Sent: Monday, May 31, 2004 1:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver verifier + ACPI S1 test fails at SCSI miniport
Hi guys,
This issue was posted a couple of times here about a month ago (see
message from David Wang 5/5/2004) but, unfortunately, I did not see
any reply with solution
When we run HCT test for our SCSI miniport driver, we have a data read
error (“Data read is not what that was expected” log message) after
system wake up from S4 in ACPI S1 Stress.
We found out that, the test ACPI S1 Stress failed any time when Force
IRQL checking and DMA checking options are enabled in Driver Verifier.
If I disable ScatterGather in SCSI miniport or make a DMA read
transfer to buffer allocated as SRB extension, the test also passes OK.
We are using Windows XP SP1 OS
Thank you in advance
Stanislav Samsonov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I get the physical address by using “ScsiPortGetPhysicalAddress”.
Bfore I send the read command to HBA,
use !dd to dump physical address and dd with the Srb->DataBuffer.
Both result show me the content of memory is the same (all 0x00000000)
At the ISR !dd with physcial address show the memory is updated.
But dd with Srb->DataBuffer, the memory is still 0x0000000…
This condition only occurred at Driver verifer + ACPI S1 test.
----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 02, 2004 4:04 AM
Subject: RE: [ntdev] Driver verifier + ACPI S1 test fails at SCSI miniport
Things to make sure of:
1) You’re getting the physical address of the buffer using
ScsiPortGetPhysicalAddress and not by calling MmGetPhysicalAddress - the
latter won’t account for DMA remapping and you will get an incorrect
result when DMA checking is enabled.
2) Make sure you’re updating DataTransferLength in the SRB correctly
after a transfer occurs.
Beyond that you probably need to watch the IO requests and see what’s
wrong with the data being returned - that may help you diagnose the
problem.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Stanislav
Samsonov
Sent: Monday, May 31, 2004 1:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver verifier + ACPI S1 test fails at SCSI miniport
Hi guys,
This issue was posted a couple of times here about a month ago (see
message from David Wang 5/5/2004) but, unfortunately, I did not see
any reply with solution
When we run HCT test for our SCSI miniport driver, we have a data read
error (“Data read is not what that was expected” log message) after
system wake up from S4 in ACPI S1 Stress.
We found out that, the test ACPI S1 Stress failed any time when Force
IRQL checking and DMA checking options are enabled in Driver Verifier.
If I disable ScatterGather in SCSI miniport or make a DMA read
transfer to buffer allocated as SRB extension, the test also passes OK.
We are using Windows XP SP1 OS
Thank you in advance
Stanislav Samsonov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@sis.com.tw
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi, guys
I succeed to get close to the problem and this is a setup that I use:
- Take PC with Windows XP SP1 and SCSI controller whose driver uses
Scatter-Gather (I also tested it with XP SP2 Release Candidate 1). 2.
Connect the single hard drive to the controller. 3. Enable “DMA checking”
option in Driver Verifier for the driver of SCSI controller. 4. Using
DskProbe.exe from XP support tools, fill a single sector on HDD with 0x0e
pattern. 5. Try to read this same sector and you never see the original data
(0x0e) in it. 6. Any other pattern (not 0x0e) does not reproduce the
problem. 7. After disabling DMA check in driver verifier the problem
disappears.
Following the SCSI read request completion, I reached in WinDbg the function
nt!ViHasBufferBeenTouched. It seems to be a function, which returns 0 if the
DMA verifier bounce buffer is filled by 0x0e and non-zero otherwise. When it
returns 0 the buffer content is simply NOT COPIED to buffer from the
original SRB request.
That is why, WHQL’s Driver verifier ACPI S1 stress test cannot pass for any
SCSI/RAID adapter with Scatter-Gather enabled, because it enables Windows
driver verifier with “DMA check” option and uses 0x0e in one of its test
patterns.
Unfortunately, it looks like a bug in OS.
Any comments?
Stanislav Samsonov
“Stanislav Samsonov” wrote in message
news:xxxxx@ntdev…
> Hi guys,
>
> This issue was posted a couple of times here about a month ago (see
message
> from David Wang 5/5/2004) but, unfortunately, I did not see any reply
with
> solution
>
> When we run HCT test for our SCSI miniport driver, we have a data read
> error (“Data read is not what that was expected” log message) after system
> wake up from S4 in ACPI S1 Stress.
>
> We found out that, the test ACPI S1 Stress failed any time when Force
IRQL
> checking and DMA checking options are enabled in Driver Verifier.
>
> If I disable ScatterGather in SCSI miniport or make a DMA read transfer
to
> buffer allocated as SRB extension, the test also passes OK.
>
> We are using Windows XP SP1 OS
>
> Thank you in advance
>
> Stanislav Samsonov
>
>
>
>
>
>
>
Nice catch. This has to be a classic “oops”.
=====================
Mark Roddy
-----Original Message-----
From: Stanislav Samsonov [mailto:samsonov@il.marvell.com]
Sent: Wednesday, June 02, 2004 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver verifier + ACPI S1 test fails at
SCSI miniport
Hi, guys
I succeed to get close to the problem and this is a setup that I use:
- Take PC with Windows XP SP1 and SCSI controller whose
driver uses Scatter-Gather (I also tested it with XP SP2
Release Candidate 1). 2.
Connect the single hard drive to the controller. 3. Enable
“DMA checking”
option in Driver Verifier for the driver of SCSI controller.
- Using DskProbe.exe from XP support tools, fill a single
sector on HDD with 0x0e pattern. 5. Try to read this same
sector and you never see the original data
(0x0e) in it. 6. Any other pattern (not 0x0e) does not
reproduce the problem. 7. After disabling DMA check in driver
verifier the problem disappears.
Following the SCSI read request completion, I reached in
WinDbg the function nt!ViHasBufferBeenTouched. It seems to be
a function, which returns 0 if the DMA verifier bounce buffer
is filled by 0x0e and non-zero otherwise. When it returns 0
the buffer content is simply NOT COPIED to buffer from the
original SRB request.
That is why, WHQL’s Driver verifier ACPI S1 stress test
cannot pass for any SCSI/RAID adapter with Scatter-Gather
enabled, because it enables Windows driver verifier with “DMA
check” option and uses 0x0e in one of its test patterns.
Unfortunately, it looks like a bug in OS.
Any comments?
Stanislav Samsonov
“Stanislav Samsonov” wrote in
> message news:xxxxx@ntdev…
> > Hi guys,
> >
> > This issue was posted a couple of times here about a month ago (see
> message
> > from David Wang 5/5/2004) but, unfortunately, I did not see any
> > reply
> with
> > solution
> >
> > When we run HCT test for our SCSI miniport driver, we have
> a data read
> > error (“Data read is not what that was expected” log message) after
> > system wake up from S4 in ACPI S1 Stress.
> >
> > We found out that, the test ACPI S1 Stress failed any time
> when Force
> IRQL
> > checking and DMA checking options are enabled in Driver Verifier.
> >
> > If I disable ScatterGather in SCSI miniport or make a DMA read
> > transfer
> to
> > buffer allocated as SRB extension, the test also passes OK.
> >
> > We are using Windows XP SP1 OS
> >
> > Thank you in advance
> >
> > Stanislav Samsonov
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
I checked with the guys who own the DMA verifer, and they say it’s a
known issue that’s fixed in Server 2003 SP1.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Wednesday, June 02, 2004 6:14 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Driver verifier + ACPI S1 test fails at SCSI
miniport
Nice catch. This has to be a classic “oops”.
=====================
Mark Roddy
-----Original Message-----
From: Stanislav Samsonov [mailto:samsonov@il.marvell.com]
Sent: Wednesday, June 02, 2004 5:25 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver verifier + ACPI S1 test fails at SCSI
miniport
Hi, guys
I succeed to get close to the problem and this is a setup that I use:
- Take PC with Windows XP SP1 and SCSI controller whose driver uses
Scatter-Gather (I also tested it with XP SP2 Release Candidate 1). 2.
Connect the single hard drive to the controller. 3. Enable “DMA
checking”
option in Driver Verifier for the driver of SCSI controller.
- Using DskProbe.exe from XP support tools, fill a single sector on
HDD with 0x0e pattern. 5. Try to read this same sector and you never
see the original data
(0x0e) in it. 6. Any other pattern (not 0x0e) does not reproduce the
problem. 7. After disabling DMA check in driver verifier the problem
disappears.
Following the SCSI read request completion, I reached in WinDbg the
function nt!ViHasBufferBeenTouched. It seems to be a function, which
returns 0 if the DMA verifier bounce buffer is filled by 0x0e and
non-zero otherwise. When it returns 0 the buffer content is simply NOT
COPIED to buffer from the original SRB request.
That is why, WHQL’s Driver verifier ACPI S1 stress test cannot pass
for any SCSI/RAID adapter with Scatter-Gather enabled, because it
enables Windows driver verifier with “DMA check” option and uses 0x0e
in one of its test patterns.
Unfortunately, it looks like a bug in OS.
Any comments?
Stanislav Samsonov
“Stanislav Samsonov” wrote in message
> news:xxxxx@ntdev…
> > Hi guys,
> >
> > This issue was posted a couple of times here about a month ago (see
> message
> > from David Wang 5/5/2004) but, unfortunately, I did not see any
> > reply
> with
> > solution
> >
> > When we run HCT test for our SCSI miniport driver, we have
> a data read
> > error (“Data read is not what that was expected” log message) after
> > system wake up from S4 in ACPI S1 Stress.
> >
> > We found out that, the test ACPI S1 Stress failed any time
> when Force
> IRQL
> > checking and DMA checking options are enabled in Driver Verifier.
> >
> > If I disable ScatterGather in SCSI miniport or make a DMA read
> > transfer
> to
> > buffer allocated as SRB extension, the test also passes OK.
> >
> > We are using Windows XP SP1 OS
> >
> > Thank you in advance
> >
> > Stanislav Samsonov
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thank you Peter,
Are there any plans to fix it in Windows XP as well? In current situation,
the SCSI miniport driver still cannot pass WHQL test for Windows XP.
Stanislav Samsonov
“Peter Wieland” wrote in message
news:xxxxx@ntdev…
I checked with the guys who own the DMA verifer, and they say it’s a
known issue that’s fixed in Server 2003 SP1.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Wednesday, June 02, 2004 6:14 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Driver verifier + ACPI S1 test fails at SCSI
miniport
Nice catch. This has to be a classic “oops”.
=====================
Mark Roddy
> -----Original Message-----
> From: Stanislav Samsonov [mailto:samsonov@il.marvell.com]
> Sent: Wednesday, June 02, 2004 5:25 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Driver verifier + ACPI S1 test fails at SCSI
> miniport
>
> Hi, guys
>
> I succeed to get close to the problem and this is a setup that I use:
>
> 1. Take PC with Windows XP SP1 and SCSI controller whose driver uses
> Scatter-Gather (I also tested it with XP SP2 Release Candidate 1). 2.
> Connect the single hard drive to the controller. 3. Enable “DMA
> checking”
> option in Driver Verifier for the driver of SCSI controller.
> 4. Using DskProbe.exe from XP support tools, fill a single sector on
> HDD with 0x0e pattern. 5. Try to read this same sector and you never
> see the original data
> (0x0e) in it. 6. Any other pattern (not 0x0e) does not reproduce the
> problem. 7. After disabling DMA check in driver verifier the problem
> disappears.
>
> Following the SCSI read request completion, I reached in WinDbg the
> function nt!ViHasBufferBeenTouched. It seems to be a function, which
> returns 0 if the DMA verifier bounce buffer is filled by 0x0e and
> non-zero otherwise. When it returns 0 the buffer content is simply NOT
> COPIED to buffer from the original SRB request.
>
> That is why, WHQL’s Driver verifier ACPI S1 stress test cannot pass
> for any SCSI/RAID adapter with Scatter-Gather enabled, because it
> enables Windows driver verifier with “DMA check” option and uses 0x0e
> in one of its test patterns.
>
> Unfortunately, it looks like a bug in OS.
>
> Any comments?
>
> Stanislav Samsonov
>
> “Stanislav Samsonov” wrote in message
> news:xxxxx@ntdev…
> > Hi guys,
> >
> > This issue was posted a couple of times here about a month ago (see
> message
> > from David Wang 5/5/2004) but, unfortunately, I did not see any
> > reply
> with
> > solution
> >
> > When we run HCT test for our SCSI miniport driver, we have
> a data read
> > error (“Data read is not what that was expected” log message) after
> > system wake up from S4 in ACPI S1 Stress.
> >
> > We found out that, the test ACPI S1 Stress failed any time
> when Force
> IRQL
> > checking and DMA checking options are enabled in Driver Verifier.
> >
> > If I disable ScatterGather in SCSI miniport or make a DMA read
> > transfer
> to
> > buffer allocated as SRB extension, the test also passes OK.
> >
> > We are using Windows XP SP1 OS
> >
> > Thank you in advance
> >
> > Stanislav Samsonov
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com