problems with requesting bandwidth for a 1394 device on Win2k SP4 and WinXP SP1

Hi all,

I wrote a driver for a 1394 device using isoch and asynch packets. I
finished my job successfully more than one year ago and it was running
without any problem on Win2k systems (notebooks) SP1. Then somebody
carried in a virus and we updated all the machines to Service Pack 4 and
oh god, the driver didn’t work any more! The same happened after we
tried it on WinXP SP1. As soon as the driver asked for isoch bandwidth
with REQUEST_ISOCH_ALLOCATE_BANDWIDTH the ohci gave back an error. We
requested 4096 bytes per frame on full speed (SPEED_FLAGS_400). The
return value from IoCallDriver() is STATUS_INSUFFICIENT_RESOURCES.
What’s wrong? Why could I do that in Win 2k SP1 but SP4 and WinXP not?
Was something “fixed” in SP4 what can cause this problem?

Thanks for every help!
Daniel

I don’t have the spec in front of me so I can’t remember the exact values,
but let me see if I have this straight. Your driver attempted to allocate
*all* of the isoch bandwidth and failed if it could not get it? The
difference on the later SPs and XP is very likely that your driver is no
longer the only entity requesting isoch bandwidth. No mystery.

Your driver should attempt to allocate the max bandwidth it needs, if the
allocation fails, check the remaining available bandwidth and attempt to
allocate that amount. If that request fails, again check the remaining
available bandwidth and attempt to allocate that amount. If that request
fails…well you get the idea. Keep scaling down until you succeed, or
until the amount of available bandwidth is lower than your driver can use.

BTW, bandwidth should be allocated as needed, and freed immediately when not
being used as other drivers may need this bandwidth. Also, it is usually
best that these allocations happen in response to some request so that the
request can be failed due to lack of resources, and subsequently attempted
again. Resource availability can potentially fluctuate such that a failed
request could potentially succeed when retried.


Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“Daniel Luethi” wrote in message news:xxxxx@ntdev…
> Hi all,
>
> I wrote a driver for a 1394 device using isoch and asynch packets. I
> finished my job successfully more than one year ago and it was running
> without any problem on Win2k systems (notebooks) SP1. Then somebody
> carried in a virus and we updated all the machines to Service Pack 4 and
> oh god, the driver didn’t work any more! The same happened after we
> tried it on WinXP SP1. As soon as the driver asked for isoch bandwidth
> with REQUEST_ISOCH_ALLOCATE_BANDWIDTH the ohci gave back an error. We
> requested 4096 bytes per frame on full speed (SPEED_FLAGS_400). The
> return value from IoCallDriver() is STATUS_INSUFFICIENT_RESOURCES.
> What’s wrong? Why could I do that in Win 2k SP1 but SP4 and WinXP not?
> Was something “fixed” in SP4 what can cause this problem?
>
> Thanks for every help!
> Daniel
>
>

Bill McKenzie wrote:

I don’t have the spec in front of me so I can’t remember the exact values,
but let me see if I have this straight. Your driver attempted to allocate
*all* of the isoch bandwidth and failed if it could not get it? The
difference on the later SPs and XP is very likely that your driver is no
longer the only entity requesting isoch bandwidth. No mystery.

Your driver should attempt to allocate the max bandwidth it needs, if the
allocation fails, check the remaining available bandwidth and attempt to
allocate that amount. If that request fails, again check the remaining
available bandwidth and attempt to allocate that amount. If that request
fails…well you get the idea. Keep scaling down until you succeed, or
until the amount of available bandwidth is lower than your driver can use.

BTW, bandwidth should be allocated as needed, and freed immediately when not
being used as other drivers may need this bandwidth. Also, it is usually
best that these allocations happen in response to some request so that the
request can be failed due to lack of resources, and subsequently attempted
again. Resource availability can potentially fluctuate such that a failed
request could potentially succeed when retried.

OK I gonna try that, thanks. The odd thing is just that there IS no
other device plugged in the same 1394 network, so I don’t really see why
it shouldn’t be able to get the whole bandwidth. Nevertheless, I
will check how much bandwidth is available and try again to allocate.
thanks and regards
Daniel

> OK I gonna try that, thanks. The odd thing is just that there IS no

other device plugged in the same 1394 network, so I don’t really see why
it shouldn’t be able to get the whole bandwidth.

Actually, on XP, while there may be no other physical devices there are
virtual devices, such as the native 1394 NIC, so your driver isn’t alone. A
robust driver will never assume that anyway.

HTH.


Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“Daniel Luethi” wrote in message news:xxxxx@ntdev…
> Bill McKenzie wrote:
> > I don’t have the spec in front of me so I can’t remember the exact
values,
> > but let me see if I have this straight. Your driver attempted to
allocate
> > all of the isoch bandwidth and failed if it could not get it? The
> > difference on the later SPs and XP is very likely that your driver is no
> > longer the only entity requesting isoch bandwidth. No mystery.
> >
> > Your driver should attempt to allocate the max bandwidth it needs, if
the
> > allocation fails, check the remaining available bandwidth and attempt to
> > allocate that amount. If that request fails, again check the remaining
> > available bandwidth and attempt to allocate that amount. If that
request
> > fails…well you get the idea. Keep scaling down until you succeed, or
> > until the amount of available bandwidth is lower than your driver can
use.
> >
> > BTW, bandwidth should be allocated as needed, and freed immediately when
not
> > being used as other drivers may need this bandwidth. Also, it is
usually
> > best that these allocations happen in response to some request so that
the
> > request can be failed due to lack of resources, and subsequently
attempted
> > again. Resource availability can potentially fluctuate such that a
failed
> > request could potentially succeed when retried.
> >
> OK I gonna try that, thanks. The odd thing is just that there IS no
> other device plugged in the same 1394 network, so I don’t really see why
> it shouldn’t be able to get the whole bandwidth. Nevertheless, I
> will check how much bandwidth is available and try again to allocate.
> thanks and regards
> Daniel
>
>