1394 isoch stream corruption

Hi,
I am working on a driver for a firewire device, but I have run into a
problem with the isochronous streaming code.
The Windows 7 1394 driver stack seems to be returning incompletely-filled
buffers in certain cases. I can reproduce this problem 100% of the time by
triggering the User Access Control screen blackout (by launching mmc, or any
other administrator-only operation) but it seems to also happen randomly
when running at S800 speeds.
If I start ‘mmc’ while the isochronous stream is running, every receive
buffer that was attached when the screen goes blank is only partially filled
when I detach it later.

The sequence of events:

  1. I write a pattern to the receive buffer I am about to attach
  2. I attach the buffer to the 1394 driver
  3. I receive the callback signaling that the buffer is completely filled
  4. I detach the buffer from the 1394 driver

But when I detach the buffer, only about 1/5 to 1/3 of the buffer is filled
with data, the rest still contains the bit pattern from step 1, even though
the 1394 header claims the buffer is the full length.

Has anybody else run into this problem before? Are there any known
workarounds?

Thanks a lot,
~Leif

Are you using buffer fill mode or packet per buffer mode?
/Uwe

Am 13.10.2010 00:54, schrieb Leif Ames:

Hi,
I am working on a driver for a firewire device, but I have run into a
problem with the isochronous streaming code.
The Windows 7 1394 driver stack seems to be returning
incompletely-filled buffers in certain cases. I can reproduce this
problem 100% of the time by triggering the User Access Control screen
blackout (by launching mmc, or any other administrator-only operation)
but it seems to also happen randomly when running at S800 speeds.
If I start ‘mmc’ while the isochronous stream is running, every
receive buffer that was attached when the screen goes blank is only
partially filled when I detach it later.

The sequence of events:

  1. I write a pattern to the receive buffer I am about to attach
  2. I attach the buffer to the 1394 driver
  3. I receive the callback signaling that the buffer is completely filled
  4. I detach the buffer from the 1394 driver

But when I detach the buffer, only about 1/5 to 1/3 of the buffer is
filled with data, the rest still contains the bit pattern from step 1,
even though the 1394 header claims the buffer is the full length.

Has anybody else run into this problem before? Are there any known
workarounds?

Thanks a lot,
~Leif

I am using packet per buffer mode.

~Leif

On Wed, Oct 13, 2010 at 1:49 AM, uwekirst wrote:

> Are you using buffer fill mode or packet per buffer mode?
> /Uwe
>
> Am 13.10.2010 00:54, schrieb Leif Ames:
>
> Hi,
> I am working on a driver for a firewire device, but I have run into a
> problem with the isochronous streaming code.
> The Windows 7 1394 driver stack seems to be returning incompletely-filled
> buffers in certain cases. I can reproduce this problem 100% of the time by
> triggering the User Access Control screen blackout (by launching mmc, or any
> other administrator-only operation) but it seems to also happen randomly
> when running at S800 speeds.
> If I start ‘mmc’ while the isochronous stream is running, every receive
> buffer that was attached when the screen goes blank is only partially filled
> when I detach it later.
>
> The sequence of events:
> 1. I write a pattern to the receive buffer I am about to attach
> 2. I attach the buffer to the 1394 driver
> 3. I receive the callback signaling that the buffer is completely filled
> 4. I detach the buffer from the 1394 driver
>
> But when I detach the buffer, only about 1/5 to 1/3 of the buffer is
> filled with data, the rest still contains the bit pattern from step 1, even
> though the 1394 header claims the buffer is the full length.
>
> Has anybody else run into this problem before? Are there any known
> workarounds?
>
> Thanks a lot,
> ~Leif
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Did you make sure that you allcote your buffer memory below 4GB?
/Uwe

Am 13.10.2010 22:04, schrieb Leif Ames:

I am using packet per buffer mode.

~Leif

On Wed, Oct 13, 2010 at 1:49 AM, uwekirst > mailto:xxxxx> wrote:
>
> Are you using buffer fill mode or packet per buffer mode?
> /Uwe
>
> Am 13.10.2010 00:54, schrieb Leif Ames:
>> Hi,
>> I am working on a driver for a firewire device, but I have run
>> into a problem with the isochronous streaming code.
>> The Windows 7 1394 driver stack seems to be returning
>> incompletely-filled buffers in certain cases. I can reproduce
>> this problem 100% of the time by triggering the User Access
>> Control screen blackout (by launching mmc, or any other
>> administrator-only operation) but it seems to also happen
>> randomly when running at S800 speeds.
>> If I start ‘mmc’ while the isochronous stream is running, every
>> receive buffer that was attached when the screen goes blank is
>> only partially filled when I detach it later.
>>
>> The sequence of events:
>> 1. I write a pattern to the receive buffer I am about to attach
>> 2. I attach the buffer to the 1394 driver
>> 3. I receive the callback signaling that the buffer is completely
>> filled
>> 4. I detach the buffer from the 1394 driver
>>
>> But when I detach the buffer, only about 1/5 to 1/3 of the buffer
>> is filled with data, the rest still contains the bit pattern from
>> step 1, even though the 1394 header claims the buffer is the full
>> length.
>>
>> Has anybody else run into this problem before? Are there any
>> known workarounds?
>>
>> Thanks a lot,
>> ~Leif
>>
>>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
> visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>