WDM USB driver trouble under vista

zantetsu says:
========================================================
I created WDM USB driver for Windows 2000 and XP.
Our device has no memory.
So the transfer shouldn't stop.
If the transfer stops, the stop period is limited about 50 micro
seconds.
I could get data from our device under Windows 2000 and XP.

I could not get a part of data under Vista.
I found that
the transfer stops during 125 micro seconds per 512k bytes transfer
under Vista.

What should I do?

Thanks.
==========================================================

I have the same problem ( a time-gap about 3 milisecond after 512k,
each time ) in same situation now. Anyone knows how to solve this
problem ?

Thanks

Tim
Sun May 11 18:01:38 CDT 2008

Hua.watson@gmail.com wrote:
>
>I created WDM USB driver for Windows 2000 and XP.
>Our device has no memory.
>So the transfer shouldn't stop.
>If the transfer stops, the stop period is limited about 50 micro
>seconds.

Then your design is hopelessly broken. Windows is not a real-time system;
you don't get this kind of guarantee.

>I found that the transfer stops during 125 micro seconds per 512k bytes
>transfer under Vista.

Are you sure you have sufficient requests queued up? If the host
controller gets to the start of a microframe and you don't have a request
queued up, then you'll miss that microframe.

>What should I do?

Have you tried SP1 yet? There were a couple of issues with isochronous
transfers in Vista that are rumored to be fixed in SP1. It would be worth
a try.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Hua
Sun May 11 21:37:25 CDT 2008

On May 12, 7:01=A0am, Tim Roberts <t...@probo.com> wrote:
> Hua.wat...@gmail.com wrote:
>
> >I created WDM USB driver for Windows 2000 and XP.
> >Our device has no memory.
> >So the transfer shouldn't stop.
> >If the transfer stops, the stop period is limited about 50 micro
> >seconds.
>
> Then your design is hopelessly broken. =A0Windows is not a real-time syste=
m;
> you don't get this kind of guarantee.
>
Yes, we known this. Anyway, our desgin need not get each frame. We
only want to get most of the frames. Eyes of human do not care loss 1
or 2 frames.
Our solution can work in XP, more than 90% frames can be get
successfully, that is enough. But in Vista, almost none frames can be
get.

> >I found that the transfer stops during 125 micro seconds per 512k bytes
> >transfer under Vista.
>
> Are you sure you have sufficient requests queued up? =A0If the host
> controller gets to the start of a microframe and you don't have a request
> queued up, then you'll miss that microframe.
Yes, we are sure that sufficient requests queued up. And, thermiss of
microframe happens not between IRPs, But ' INSIDE ' 1 IRP. For
example, the IRP requires 829440 bytes, after read of 512k bytes,
several microframes miss, then continue.
I am not sure whether the lower FiDO of windows itself will ro will
not cut my big IRP to several parts.

>
> >What should I do?
>
> Have you tried SP1 yet? =A0There were a couple of issues with isochronous
> transfers in Vista that are rumored to be fixed in SP1. =A0It would be wor=
th
> a try.
There is no difference before and after the update of SP1. We use
VISTA home basic 6.0.6000 and 6.0.6001.

Thanks

> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

Hua
Mon May 12 08:07:19 CDT 2008

On 5=D4=C212=C8=D5, =C9=CF=CE=E710=CA=B137=B7=D6, Hua.wat...@gmail.com wrote=
:
> On May 12, 7:01 am, Tim Roberts <t...@probo.com> wrote:> Hua.wat...@gmail.=
com wrote:
>
> > >I created WDM USB driver for Windows 2000 and XP.
> > >Our device has no memory.
> > >So the transfer shouldn't stop.
> > >If the transfer stops, the stop period is limited about 50 micro
> > >seconds.
>
> > Then your design is hopelessly broken. Windows is not a real-time syste=
m;
> > you don't get this kind of guarantee.
>
> Yes, we known this. Anyway, our desgin need not get each frame. We
> only want to get most of the frames. Eyes of human do not care loss 1
> or 2 frames.
> Our solution can work in XP, more than 90% frames can be get
> successfully, that is enough. But in Vista, almost none frames can be
> get.
>
> > >I found that the transfer stops during 125 micro seconds per 512k bytes=

> > >transfer under Vista.
>
> > Are you sure you have sufficient requests queued up? If the host
> > controller gets to the start of a microframe and you don't have a reques=
t
> > queued up, then you'll miss that microframe.
>
> Yes, we are sure that sufficient requests queued up. And, thermiss of
> microframe happens not between IRPs, But ' INSIDE ' 1 IRP. For
> example, the IRP requires 829440 bytes, after read of 512k bytes,
> several microframes miss, then continue.
> I am not sure whether the lower FiDO of windows itself will ro will
> not cut my big IRP to several parts.
>
>
>
> > >What should I do?
>
> > Have you tried SP1 yet? There were a couple of issues with isochronous
> > transfers in Vista that are rumored to be fixed in SP1. It would be wor=
th
> > a try.
>
> There is no difference before and after the update of SP1. We use
> VISTA home basic 6.0.6000 and 6.0.6001.
>
> Thanks
>
> > --
> > Tim Roberts, t...@probo.com
> > Providenza & Boekelheide, Inc.

Append: Today, I tried to divide the 800k IRP into several 256k or
512k URBs in my WDM driver, and send them one after another is
complete. But there are still time-gap between URBs. Should I or can I
send more than one URBs to the system PDO ? ( once a URB is finished,
system can immediately ask for data to fill the next URB without call
my FDO WDM driver. In fact, I used to think if I send a big URB of
800k, system USB PDO driver will do this automaticly. )

Tim
Tue May 13 23:39:53 CDT 2008

Hua.watson@gmail.com wrote:
>
>Append: Today, I tried to divide the 800k IRP into several 256k or
>512k URBs in my WDM driver, and send them one after another is
>complete. But there are still time-gap between URBs. Should I or can I
>send more than one URBs to the system PDO ? ( once a URB is finished,
>system can immediately ask for data to fill the next URB without call
>my FDO WDM driver. In fact, I used to think if I send a big URB of
>800k, system USB PDO driver will do this automaticly. )

To guarantee uninterrupted service, you MUST have multiple URBs queued up
at any given time. By the time one URB is completed, you have already
missed the next microframe, without even considering the turnaround time.

800kB is a lot for a single isochronous URB. For a maximum bandwidth
endpoint, that one URB will span 256 microframes. I'd rather queue up 8
URBs with 100kB each.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Hua
Wed May 14 01:31:21 CDT 2008

On May 14, 12:39=A0pm, Tim Roberts <t...@probo.com> wrote:
> Hua.wat...@gmail.com wrote:
>
> >Append: Today, I tried to divide the 800k IRP into several 256k or
> >512k URBs in my WDM driver, and send them one after another is
> >complete. But there are still time-gap between URBs. Should I or can I
> >send more than one URBs to the system PDO ? ( once a URB is finished,
> >system can immediately ask for data to fill the next URB without call
> >my FDO WDM driver. In fact, I used to think if I send a big URB of
> >800k, system USB PDO driver will do this automaticly. )
>
> To guarantee uninterrupted service, you MUST have multiple URBs queued up
> at any given time. =A0By the time one URB is completed, you have already
> missed the next microframe, without even considering the turnaround time.
>
> 800kB is a lot for a single isochronous URB. =A0For a maximum bandwidth
> endpoint, that one URB will span 256 microframes. =A0I'd rather queue up 8=

> URBs with 100kB each.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

We use Bulk.
Now, our driver work this way: (when it get a IRP)
create urb for first 256k, then send the IRP by IoCallDriver()
in the completionRoutine function of this IRP, we call
MmPrepareMdlForReuse() and IoBuildPartialMdl() and other needed, then
re-send the IRP by IoCallDriver() in IoQueueWorkItem().
So our URBs is queued in driver and the next URB will NOT send if the
URB before have not been completed.

You mean we MUST have multiple URBs queued up at any given time. Do
you mean we should send the 8 of 100k URBs together down to the PDO
and make them queued in PDO? But windows do not support linked URBs
in one IRP.

So what shoud I do ?

Thanks.

Maxim
Wed May 14 18:24:14 CDT 2008

>and make them queued in PDO? But windows do not support linked URBs
>in one IRP.

Send several IRPs.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Hua
Thu May 15 08:29:33 CDT 2008

On 5=D4=C215=C8=D5, =C9=CF=CE=E77=CA=B124=B7=D6, "Maxim S. Shatskih" <ma...@=
storagecraft.com> wrote:
> >and make them queued in PDO? But windows do not support linked URBs
> >in one IRP.
>
> Send several IRPs.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> ma...@storagecraft.comhttp://www.storagecraft.com

Thanks, now the speed is ok and most of frames can be transfered
completely.
But there is a new problem. In my solution, when fifo of device(68013)
is full, firmware will send a short packet to end the current transfer
(a frame). Then send the next frame when host request it. Now, the
transfer is breaked to several sub irps. If the fifo full happened in
the middle sub transfer. The firmware will treat the next sub irp as
the request of next frame. This make the picture wrong, once the fifo
is full.
I think it is not assured that I can cancel the rest sub irps fast
enough in complete routine of sub irps.
And good ideas ?

Tim
Thu May 15 22:10:57 CDT 2008

Hua.watson@gmail.com wrote:
>
>Thanks, now the speed is ok and most of frames can be transfered
>completely.
>But there is a new problem. In my solution, when fifo of device(68013)
>is full, firmware will send a short packet to end the current transfer
>(a frame). Then send the next frame when host request it. Now, the
>transfer is breaked to several sub irps. If the fifo full happened in
>the middle sub transfer. The firmware will treat the next sub irp as
>the request of next frame. This make the picture wrong, once the fifo
>is full.
>I think it is not assured that I can cancel the rest sub irps fast
>enough in complete routine of sub irps.
>And good ideas ?

You will certainly know when you receive a short frame, because the
returned length in the URB will be less than the buffer size. If that
happens, then your driver knows that the frame ended, and the next buffer
it gets is the start of a new frame.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Hua
Thu May 15 22:36:15 CDT 2008

On May 16, 11:10=A0am, Tim Roberts <t...@probo.com> wrote:
> Hua.wat...@gmail.com wrote:
>
> >Thanks, now the speed is ok and most of frames can be transfered
> >completely.
> >But there is a new problem. In my solution, when fifo of device(68013)
> >is full, firmware will send a short packet to end the current transfer
> >(a frame). Then send the next frame when host request it. Now, the
> >transfer is breaked to several sub irps. If the fifo full happened in
> >the middle sub transfer. The firmware will treat the next sub irp as
> >the request of next frame. This make the picture wrong, once the fifo
> >is full.
> >I think it is not assured that I can cancel the rest sub irps fast
> >enough in complete routine of sub irps.
> >And good ideas ?
>
> You will certainly know when you receive a short frame, because the
> returned length in the URB will be less than the buffer size. =A0If that
> happens, then your driver knows that the frame ended, and the next buffer
> it gets is the start of a new frame.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

Yes, now I use the code below:
if (InterlockedDecrement(&(pFx2Context->numpending)) =3D=3D 0){
if (IoSetCancelRoutine(mainirp, NULL)){
InterlockedDecrement(&(pFx2Context->refcnt)); // cancel routine can
no longer run
}
pFx2Context->status =3D status;
mainirp->IoStatus.Status =3D pFx2Context->status;
IoCompleteRequest(mainirp, IO_NO_INCREMENT);
}// complete main IRP
else{
//Fixme: may have problem
if( urb->UrbIsochronousTransfer.TransferBufferLength < pFx2Context-
>MaxmimumStageSize ){
if( pFx2Context->DevExt->FLAG_VIDEO_FIFOFULL =3D=3D 0){
pFx2Context->DevExt->FLAG_VIDEO_FIFOFULL =3D 1;
}
for (ULONG i =3D pFx2Context->numirps - pFx2Context->numpending; i <
pFx2Context->numirps; ++i){
IoCancelIrp(pFx2Context->subs[i].irp);
}
if (IoSetCancelRoutine(mainirp, NULL)){
InterlockedDecrement(&(pFx2Context->refcnt)); // cancel routine
can no longer run
}
pFx2Context->status =3D status;
mainirp->IoStatus.Status =3D pFx2Context->status;
IoCompleteRequest(mainirp, IO_NO_INCREMENT);
}
}
It works
but I have two problem that :
1. Only on XP, there will be very often blue screens
"bugcode_usb_driver", in vista it is now problem
2. In both XP and Vista, there will be blue screen
"MULTIPLE_IRP_COMPLIETE_REQUESTS", if I take the device off from PC
while application is running.

Why will them happen ?

Thanks

Hua
Thu May 15 23:18:35 CDT 2008


> Yes, now I use the code below:
> =A0 =A0 =A0 =A0 if (InterlockedDecrement(&(pFx2Context->numpending)) =3D=
=3D 0){
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (IoSetCancelRoutine(mainirp, NULL)){
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 InterlockedDecrement(&(pFx=
2Context->refcnt)); =A0 =A0// cancel routine can
> no longer run
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pFx2Context->status =3D status;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mainirp->IoStatus.Status =3D pFx2Context->=
status;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IoCompleteRequest(mainirp, IO_NO_INCREMENT=
);
> =A0 =A0 =A0 =A0 }// complete main IRP
> =A0 =A0 =A0 =A0 else{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //Fixme: may have problem
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if( urb->UrbIsochronousTransfer.TransferBu=
fferLength < pFx2Context->MaxmimumStageSize ){
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if( pFx2Context->DevExt->F=
LAG_VIDEO_FIFOFULL =3D=3D 0){
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pFx2Contex=
t->DevExt->FLAG_VIDEO_FIFOFULL =3D 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ULONG i =3D pFx2Conte=
xt->numirps - pFx2Context->numpending; i <
> pFx2Context->numirps; ++i){
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IoCancelIr=
p(pFx2Context->subs[i].irp);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (IoSetCancelRoutine(mai=
nirp, NULL)){
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Interlocke=
dDecrement(&(pFx2Context->refcnt)); =A0 =A0// cancel routine
> can no longer run
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pFx2Context->status =3D st=
atus;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mainirp->IoStatus.Status =
=3D pFx2Context->status;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IoCompleteRequest(mainirp,=
IO_NO_INCREMENT);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> It works
> but I have two problem that :
> 1. Only on XP, there will be very often blue screens
> "bugcode_usb_driver", =A0in vista there is no problem
sorry,now I find maybe the error condition is working together with a
usb mouse in the same hub/controller.
> 2. In both XP and Vista, there will be blue screen
> "MULTIPLE_IRP_COMPLIETE_REQUESTS", if I take the device off from PC
> while application is running.
>
> Why will them happen ?
>
> Thanks- Hide quoted text -
>
> - Show quoted text -