Within my driver a Isoch Listen call of the 1394 bus driver returns now
0xc000009a (insufficiant resources).
Any ideas?
(It worked under Vista)
Allocating the resources seem to work though.
Thanks
/Uwe
Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
Peter
Hello Peter,
yes, of course.
I noticed another strange thing, dont know wether related to this:
REQUEST_GET_SPEED_BETWEEN_DEVICES returns 0x2 (SPEED_FLAGS_200), I would
expect 0x4 (SPEED_FLAGS_400)
Maybee the result is always decoded as if USE_SCODE_SPEED flag is set
(actually it is not set).
Thanks,
/Uwe
xxxxx@microsoft.com schrieb:
Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
Peter
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Do you have a 1394 bus analyzer to see what speed the async packets are sent on the bus?
The speed should match what is returned on the REQUEST_GET_SPEED_BETWEEN_DEVICES request. The speed is determined after a 1394 bus reset when the 1394 bus driver initially attempts to enumerate your device.
Can you try specifying the USE_SCODE_SPEED flag in GetMaxSpeedBetweenDevices.fulFlags and verify that 0x1 is returned (SCODE_200_RATE)?
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Wednesday, July 01, 2009 1:55 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
Hello Peter,
yes, of course.
I noticed another strange thing, dont know wether related to this:
REQUEST_GET_SPEED_BETWEEN_DEVICES returns 0x2 (SPEED_FLAGS_200), I would
expect 0x4 (SPEED_FLAGS_400)
Maybee the result is always decoded as if USE_SCODE_SPEED flag is set
(actually it is not set).
Thanks,
/Uwe
xxxxx@microsoft.com schrieb:
Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
Peter
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo 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
SCODE decoding seems to be consistant, but also wrong:
GetMaxSpeedBetweenDevices returns 0x1 == SCODE_200_RATE in this case.
I noticed further issues:
If I connect two devices (different GUIDs of course) and a turn on the
second one, the second one is not detected and the first device stops
working. All accesses to the first device fail.
Thanks,
/Uwe
Peter Binder schrieb:
Do you have a 1394 bus analyzer to see what speed the async packets are sent on the bus?
The speed should match what is returned on the REQUEST_GET_SPEED_BETWEEN_DEVICES request. The speed is determined after a 1394 bus reset when the 1394 bus driver initially attempts to enumerate your device.
Can you try specifying the USE_SCODE_SPEED flag in GetMaxSpeedBetweenDevices.fulFlags and verify that 0x1 is returned (SCODE_200_RATE)?
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Wednesday, July 01, 2009 1:55 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)Hello Peter,
yes, of course.I noticed another strange thing, dont know wether related to this:
REQUEST_GET_SPEED_BETWEEN_DEVICES returns 0x2 (SPEED_FLAGS_200), I would
expect 0x4 (SPEED_FLAGS_400)
Maybee the result is always decoded as if USE_SCODE_SPEED flag is set
(actually it is not set).Thanks,
/Uwexxxxx@microsoft.com schrieb:
> Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
>
> This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
>
> Peter
>
>
> —
> 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/seminarsTo 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/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
This means that the 1394 bus driver is communicating with your device at S200. With the Windows 7 1394 bus driver, the speed to communicate to the device is determined during device enumeration after a 1394 bus reset.
The 1394 whitepaper (http://www.microsoft.com/whdc/connect/1394_Windows7.mspx) describes this process in more detail.
In order to determine why this is happening, we’d need to look at either a 1394 bus trace or log output from the 1394 bus driver.
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Thursday, July 02, 2009 2:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
SCODE decoding seems to be consistant, but also wrong:
GetMaxSpeedBetweenDevices returns 0x1 == SCODE_200_RATE in this case.
I noticed further issues:
If I connect two devices (different GUIDs of course) and a turn on the
second one, the second one is not detected and the first device stops
working. All accesses to the first device fail.
Thanks,
/Uwe
Peter Binder schrieb:
Do you have a 1394 bus analyzer to see what speed the async packets are sent on the bus?
The speed should match what is returned on the REQUEST_GET_SPEED_BETWEEN_DEVICES request. The speed is determined after a 1394 bus reset when the 1394 bus driver initially attempts to enumerate your device.
Can you try specifying the USE_SCODE_SPEED flag in GetMaxSpeedBetweenDevices.fulFlags and verify that 0x1 is returned (SCODE_200_RATE)?
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Wednesday, July 01, 2009 1:55 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)Hello Peter,
yes, of course.I noticed another strange thing, dont know wether related to this:
REQUEST_GET_SPEED_BETWEEN_DEVICES returns 0x2 (SPEED_FLAGS_200), I would
expect 0x4 (SPEED_FLAGS_400)
Maybee the result is always decoded as if USE_SCODE_SPEED flag is set
(actually it is not set).Thanks,
/Uwexxxxx@microsoft.com schrieb:
> Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
>
> This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
>
> Peter
>
>
> —
> 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/seminarsTo 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/seminarsTo 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
Hello Peter,
I reinstalled the busdriver.
After that it seems that I cannot reproduce the S200 issue any longer.
I would like to focus now on my other problem: How to get the
IsochListen working.
Any ideas?
I tried to install a debug version of 1394ohci.sys, but how do I enable
the debug output? I would like to uses debugview for viewing, but could
only see my own debug output so far.
Do I have to change the debuglevel somehow?
/Uwe
Peter Binder schrieb:
This means that the 1394 bus driver is communicating with your device at S200. With the Windows 7 1394 bus driver, the speed to communicate to the device is determined during device enumeration after a 1394 bus reset.
The 1394 whitepaper (http://www.microsoft.com/whdc/connect/1394_Windows7.mspx) describes this process in more detail.
In order to determine why this is happening, we’d need to look at either a 1394 bus trace or log output from the 1394 bus driver.
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Thursday, July 02, 2009 2:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)SCODE decoding seems to be consistant, but also wrong:
GetMaxSpeedBetweenDevices returns 0x1 == SCODE_200_RATE in this case.I noticed further issues:
If I connect two devices (different GUIDs of course) and a turn on the
second one, the second one is not detected and the first device stops
working. All accesses to the first device fail.Thanks,
/UwePeter Binder schrieb:
> Do you have a 1394 bus analyzer to see what speed the async packets are sent on the bus?
>
> The speed should match what is returned on the REQUEST_GET_SPEED_BETWEEN_DEVICES request. The speed is determined after a 1394 bus reset when the 1394 bus driver initially attempts to enumerate your device.
>
> Can you try specifying the USE_SCODE_SPEED flag in GetMaxSpeedBetweenDevices.fulFlags and verify that 0x1 is returned (SCODE_200_RATE)?
>
> Peter
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
> Sent: Wednesday, July 01, 2009 1:55 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
>
> Hello Peter,
> yes, of course.
>
> I noticed another strange thing, dont know wether related to this:
> REQUEST_GET_SPEED_BETWEEN_DEVICES returns 0x2 (SPEED_FLAGS_200), I would
> expect 0x4 (SPEED_FLAGS_400)
> Maybee the result is always decoded as if USE_SCODE_SPEED flag is set
> (actually it is not set).
>
> Thanks,
> /Uwe
>
>
>
> xxxxx@microsoft.com schrieb:
>
>
>> Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
>>
>> This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
>>
>> Peter
>>
>>
>> —
>> 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
>
>
> —
> 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/seminarsTo 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/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I suspect the S200 issue will occur sporadically. If you repro this again, make sure to remember the steps involved. This way you might be able to consistently reproduce and then get a bus trace to determine why S200 is selected.
The only reason an ISOCH_LISTEN would fail with STATUS_INSUFFICIENT_RESOURCES is because the 1394 bus driver detects that no isoch descriptors are attached.
We should be able to get debug output to confirm that this is happening. I’ve forwarded you instructions on how to enable this. Did you receive the e-mail?
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Thursday, July 02, 2009 1:25 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
Hello Peter,
I reinstalled the busdriver.
After that it seems that I cannot reproduce the S200 issue any longer.
I would like to focus now on my other problem: How to get the
IsochListen working.
Any ideas?
I tried to install a debug version of 1394ohci.sys, but how do I enable
the debug output? I would like to uses debugview for viewing, but could
only see my own debug output so far.
Do I have to change the debuglevel somehow?
/Uwe
Peter Binder schrieb:
This means that the 1394 bus driver is communicating with your device at S200. With the Windows 7 1394 bus driver, the speed to communicate to the device is determined during device enumeration after a 1394 bus reset.
The 1394 whitepaper (http://www.microsoft.com/whdc/connect/1394_Windows7.mspx) describes this process in more detail.
In order to determine why this is happening, we’d need to look at either a 1394 bus trace or log output from the 1394 bus driver.
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Thursday, July 02, 2009 2:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)SCODE decoding seems to be consistant, but also wrong:
GetMaxSpeedBetweenDevices returns 0x1 == SCODE_200_RATE in this case.I noticed further issues:
If I connect two devices (different GUIDs of course) and a turn on the
second one, the second one is not detected and the first device stops
working. All accesses to the first device fail.Thanks,
/UwePeter Binder schrieb:
> Do you have a 1394 bus analyzer to see what speed the async packets are sent on the bus?
>
> The speed should match what is returned on the REQUEST_GET_SPEED_BETWEEN_DEVICES request. The speed is determined after a 1394 bus reset when the 1394 bus driver initially attempts to enumerate your device.
>
> Can you try specifying the USE_SCODE_SPEED flag in GetMaxSpeedBetweenDevices.fulFlags and verify that 0x1 is returned (SCODE_200_RATE)?
>
> Peter
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
> Sent: Wednesday, July 01, 2009 1:55 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
>
> Hello Peter,
> yes, of course.
>
> I noticed another strange thing, dont know wether related to this:
> REQUEST_GET_SPEED_BETWEEN_DEVICES returns 0x2 (SPEED_FLAGS_200), I would
> expect 0x4 (SPEED_FLAGS_400)
> Maybee the result is always decoded as if USE_SCODE_SPEED flag is set
> (actually it is not set).
>
> Thanks,
> /Uwe
>
>
>
> xxxxx@microsoft.com schrieb:
>
>
>> Can you confirm that you have an attach isoch descriptor before submitting an isoch listen request?
>>
>> This behavior should be the same for the Vista and Windows 7 version of the 1394 bus driver. It is required that an isoch descriptor is attached before the run bit is set in the isoch dma context to start the stream.
>>
>> Peter
>>
>>
>> —
>> 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
>
>
> —
> 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/seminarsTo 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/seminarsTo 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
Hi, Could I also have the instructions for enabling debug? It seems an
important tool for any 1394 development… Thanks, Mike.
>>>----- Original Message -----
From: Peter Binder
To: Windows System Software Devs Interest List
Sent: Friday, July 03, 2009 1:44 AM
Subject: RE: [ntdev] 1394 bus driver changes Windows 7 (RC)
I suspect the S200 issue will occur sporadically. If you repro this again,
make sure to remember the steps involved. This way you might be able to
consistently reproduce and then get a bus trace to determine why S200 is
selected.
The only reason an ISOCH_LISTEN would fail with
STATUS_INSUFFICIENT_RESOURCES is because the 1394 bus driver detects that no
isoch descriptors are attached.
We should be able to get debug output to confirm that this is happening.
I’ve forwarded you instructions on how to enable this. Did you receive the
e-mail?
Peter
<<<<<
Hello all, Hello Peter,
I got your information about howto enable the debugging. I’m not an
expert, but it seems that I can not extract any valuable informations
form the .etl file. This may bee because I do not have the correct
symbols. I also do not have a tmf file for the ohci1394 driver. So I do
not know howto interprete the log. The GUID of the driver is included
though.
Today the S200 issue occured again, but I don’t remember what I changed.
Concerning ISOCH_LISTEN I found, that also attaching the buffers failed,
I did not noticed that before.
The returned status code is:
c000000d = STATUS_INVALID_PARAMETER
You may remember that there was a different behavior within Windows 7
BETA compared to Windows 7 RC. I reported that the beta version
bluescreens @attaching the buffers. The RC now returns
STATUS_INVALID_PARAMETER.
So please could you tell us what is the reason for all this? Older OS
version upto Vista seem to work with my driver.
I have also included the parameters of the attach buffer call (see
below). Attaching the playback (Talk) buffers, which came first (at pos.
1-5), seems to work.
Maybee someone could tell, whats wrong here (ok, some of the pointers
are not so interersting for you)
Thanks,
/Uwe
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0xc
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a7b1b4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86a02088
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82620
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 12
Frames = 47
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2f
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3ea34
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86a03918
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x1
pIsochDescriptor->ulTag = 0x1
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a821e8
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 46
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2e
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a455b4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86d03510
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x2
pIsochDescriptor->ulTag = 0x2
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82260
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 47
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2f
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a4c134
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86d04238
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x3
pIsochDescriptor->ulTag = 0x3
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a822d8
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 46
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2e
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a52cb4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86d06ed0
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x4
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82350
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e37c
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869bd4a8
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81d38
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e428
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869aee00
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81db0
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e4d4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869b03c8
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81e28
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e580
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x85c96098
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81ea0
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e62c
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86809148
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81f18
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e6d8
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869c0770
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81f90
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e784
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869c00b0
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82008
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e830
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x868419f0
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82080
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
t1394_IsochListen Enter
t1394_SubmitIrpAsync Enter
Wait completed sucessfull, ioStatus.Status = 0xc000009a
irp status direct = 0xc000009a
SubmitIrpSync failed = 0xc000009a
t1394_IsochListen Exit = c000009a
IsochListen failed with error code 0xc000009a!
Peter Binder schrieb:
I suspect the S200 issue will occur sporadically. If you repro this again, make sure to remember the steps involved. This way you might be able to consistently reproduce and then get a bus trace to determine why S200 is selected.
The only reason an ISOCH_LISTEN would fail with STATUS_INSUFFICIENT_RESOURCES is because the 1394 bus driver detects that no isoch descriptors are attached.
We should be able to get debug output to confirm that this is happening. I’ve forwarded you instructions on how to enable this. Did you receive the e-mail?
Peter
You are receiving a status_invalid_parameter because ulLength is not evenly divisible by nMaxBytesPerFrame. For isoch capture, this should always be true, but it was not enforced in the Vista 1394 driver.
This then leads to the failure on isoch_listen, because no isoch descriptors successfully attached. If you fix this issue on isoch_attach_buffers, then the isoch_listen will succeed.
If you have any questions regarding this, please let me know.
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Friday, July 03, 2009 8:33 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
Hello all, Hello Peter,
I got your information about howto enable the debugging. I’m not an
expert, but it seems that I can not extract any valuable informations
form the .etl file. This may bee because I do not have the correct
symbols. I also do not have a tmf file for the ohci1394 driver. So I do
not know howto interprete the log. The GUID of the driver is included
though.
Today the S200 issue occured again, but I don’t remember what I changed.
Concerning ISOCH_LISTEN I found, that also attaching the buffers failed,
I did not noticed that before.
The returned status code is:
c000000d = STATUS_INVALID_PARAMETER
You may remember that there was a different behavior within Windows 7
BETA compared to Windows 7 RC. I reported that the beta version
bluescreens @attaching the buffers. The RC now returns
STATUS_INVALID_PARAMETER.
So please could you tell us what is the reason for all this? Older OS
version upto Vista seem to work with my driver.
I have also included the parameters of the attach buffer call (see
below). Attaching the playback (Talk) buffers, which came first (at pos.
1-5), seems to work.
Maybee someone could tell, whats wrong here (ok, some of the pointers
are not so interersting for you)
Thanks,
/Uwe
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0xc
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a7b1b4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86a02088
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82620
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 12
Frames = 47
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2f
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3ea34
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86a03918
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x1
pIsochDescriptor->ulTag = 0x1
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a821e8
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 46
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2e
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a455b4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86d03510
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x2
pIsochDescriptor->ulTag = 0x2
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82260
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 47
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2f
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a4c134
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86d04238
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x3
pIsochDescriptor->ulTag = 0x3
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a822d8
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
Frames = 46
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x78ea94b8
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x2e
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a52cb4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86d06ed0
pIsochDescriptor->ulLength = 0x168
pIsochDescriptor->nMaxBytesPerFrame = 0x168
pIsochDescriptor->ulSynch = 0x4
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x0
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82350
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0x0
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e37c
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869bd4a8
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81d38
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e428
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869aee00
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81db0
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e4d4
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869b03c8
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81e28
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e580
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x85c96098
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81ea0
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e62c
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x86809148
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81f18
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e6d8
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869c0770
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a81f90
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e784
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x869c00b0
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82008
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
AttachIrb->FunctionNumber = 0x6
AttachIrb->Flags = 0x0
AttachIrb->u.IsochAttachBuffers.hResouce = 0x790a30d0
AttachIrb->u.IsochAttachBuffers.nNumberOfDescriptors = 0x1
AttachIrb->u.IsochAttachBuffers.pIsochDescriptior = 0x86a3e830
pIsochDescriptor->fulFlags = 0x10
pIsochDescriptor->Mdl = 0x868419f0
pIsochDescriptor->ulLength = 0x4800
pIsochDescriptor->nMaxBytesPerFrame = 0x1f8
pIsochDescriptor->ulSynch = 0x0
pIsochDescriptor->ulTag = 0x0
pIsochDescriptor->Callback = 0x82434a10
pIsochDescriptor->Context1 = 0x86a3e0e0
pIsochDescriptor->Context2 = 0x86a82080
pIsochDescriptor->status = 0x0
t1394Diag_AttachBuffers: Irp is pending…
t1394Diag_AttachBuffers status: 0xc000000d
t1394_IsochListen Enter
t1394_SubmitIrpAsync Enter
Wait completed sucessfull, ioStatus.Status = 0xc000009a
irp status direct = 0xc000009a
SubmitIrpSync failed = 0xc000009a
t1394_IsochListen Exit = c000009a
IsochListen failed with error code 0xc000009a!
Peter Binder schrieb:
I suspect the S200 issue will occur sporadically. If you repro this again, make sure to remember the steps involved. This way you might be able to consistently reproduce and then get a bus trace to determine why S200 is selected.
The only reason an ISOCH_LISTEN would fail with STATUS_INSUFFICIENT_RESOURCES is because the 1394 bus driver detects that no isoch descriptors are attached.
We should be able to get debug output to confirm that this is happening. I’ve forwarded you instructions on how to enable this. Did you receive the e-mail?
Peter
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
Hello Peter,
Peter Binder schrieb:
You are receiving a status_invalid_parameter because ulLength is not evenly divisible by nMaxBytesPerFrame. For isoch capture, this should always be true, but it was not enforced in the Vista 1394 driver.
I’m very disappointed. This is bad news since will probably break many
audio hardware devices / drivers combinations, including my own.
Its’s a big drawback compared to Vista/XP/W2K.
If the ulLength parameter must be divisible by nMaxBytePerFrame this
means that the name “nMaxBytePerFrame” is misleading. Its not a maximum
value any longer but in fact a constant.
This implies that sample rate matching by varying the framesize within
the hardware device is not possible within Windows 7.
Furthermore for audio applications latency is always a concern.
The new Win7 rule also introduces addional latency of 1 Frame, which
prevents optimal results by the new 1394ohci driver.
Its also means of course that you need additional hardware buffering of
1 Frame within the device. At the moment I can not guarantee if this is
possible with my device, I have to look into the firmware.
The parameter ulLength will be in most cases a power of two (measured in
samples, not in bytes!), because these values are compatible to most
audio applications. Some audio apps stop working, if other values are used.
The new rule implies that the nMaxBytesPerFrame parameter must also be a
power of two (again: measued in samples).
In other words: you are forced to waste bandwidth on the firefire bus,
even if you don’t need them.
Thanks,
/Uwe
As an audio developer I want to add my agreement with Uwe on this matter.
Introducing new constraints this late in the 1394 day is bad news and should
not be contemplated without adequate consultation with developers. After
all, how is the 1394 stack developer to know what is important unless they
consider all the uses to which it will be put.
I think that this sort of spec change has to be defined as a serious bug
that should be fixed ASAP. ** Not ** fixed an assertion that it was always
meant to be that way," we just never mentioned it before".
Just a reminder: MS have been smart to keep their OSes upwardly compatible.
It is a shame to drop that philosopy with Win 7.
Sorry if this sounds combatative, hopefully it can be constructive if we can
move it back to compatibility.
Regards to all… Mike
>>>>
----- Original Message -----
From: uwekirst
To: Windows System Software Devs Interest List
Sent: Wednesday, July 08, 2009 9:02 AM
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
Hello Peter,
Peter Binder schrieb:
You are receiving a status_invalid_parameter because ulLength is not
evenly divisible by nMaxBytesPerFrame. For isoch capture, this should
always be true, but it was not enforced in the Vista 1394 driver.
I’m very disappointed. This is bad news since will probably break many
audio hardware devices / drivers combinations, including my own.
Its’s a big drawback compared to Vista/XP/W2K.
If the ulLength parameter must be divisible by nMaxBytePerFrame this
means that the name “nMaxBytePerFrame” is misleading. Its not a maximum
value any longer but in fact a constant.
This implies that sample rate matching by varying the framesize within
the hardware device is not possible within Windows 7.
Furthermore for audio applications latency is always a concern.
The new Win7 rule also introduces addional latency of 1 Frame, which
prevents optimal results by the new 1394ohci driver.
Its also means of course that you need additional hardware buffering of
1 Frame within the device. At the moment I can not guarantee if this is
possible with my device, I have to look into the firmware.
The parameter ulLength will be in most cases a power of two (measured in
samples, not in bytes!), because these values are compatible to most
audio applications. Some audio apps stop working, if other values are used.
The new rule implies that the nMaxBytesPerFrame parameter must also be a
power of two (again: measued in samples).
In other words: you are forced to waste bandwidth on the firefire bus,
even if you don’t need them.
Thanks,
/Uwe
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
Hello Uwe/Mike,
I appreciate this feedback and I want to make one point clear: compatibility is our biggest concern.
When we decided to add support for 1394b in the 1394 bus driver, our biggest concern was that changes to the 1394 bus driver would break our customers. The Vista 1394 bus driver has been in its current form for about 10 years. That is a lot of compatibility to handle.
In order to mitigate any compatibility issues, we decided to also ship the legacy 1394 bus driver in Windows 7. This means that for our customers affected by changes in the new 1394 bus driver, they have a reasonable workaround to make sure that their solutions continue to work on Windows 7.
You can load the legacy 1394 bus driver using the following steps:
- In device manager, select the properties for the 1394 controller.
- Select the ‘Driver’ page and ‘Update Driver’ button.
- Select ‘Browse my computer for driver software.’
- Select ‘Let me pick from a list of device drivers on my computer.’
- Within the list of devices, you will see a device with ‘(Legacy).’ This is the 1394 bus driver that previously shipped in Windows. Select this device and select ‘Next.’
This will install the legacy 1394 bus driver on Windows 7. You can use the same steps, changing the device you select in step 5, to revert back to the new 1394 bus driver.
An important point to keep in mind is that eventually the legacy 1394 bus driver will be removed from Windows. It is provided right now for compatibility. (We really, really, really, do not want to break our customer’s scenarios.)
On this note, it is important that you continue to test your scenarios on the new 1394 bus driver and report any issues to us ASAP. The sooner an issue is reported, the quicker we can get it fixed in the new 1394 bus driver.
As for this issue, Uwe, can you send me the parameters you specify on the isoch_allocate_resources for the capture stream? I need to investigate why this check was added. This will take a little bit of time on my part, but once I understand what is happening, I will follow-up on this thread.
Please let me know you if you have any questions or comments.
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Wednesday, July 08, 2009 1:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
As an audio developer I want to add my agreement with Uwe on this matter.
Introducing new constraints this late in the 1394 day is bad news and should
not be contemplated without adequate consultation with developers. After
all, how is the 1394 stack developer to know what is important unless they
consider all the uses to which it will be put.
I think that this sort of spec change has to be defined as a serious bug
that should be fixed ASAP. ** Not ** fixed an assertion that it was always
meant to be that way," we just never mentioned it before".
Just a reminder: MS have been smart to keep their OSes upwardly compatible.
It is a shame to drop that philosopy with Win 7.
Sorry if this sounds combatative, hopefully it can be constructive if we can
move it back to compatibility.
Regards to all… Mike
>>>>
----- Original Message -----
From: uwekirst
To: Windows System Software Devs Interest List
Sent: Wednesday, July 08, 2009 9:02 AM
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
Hello Peter,
Peter Binder schrieb:
You are receiving a status_invalid_parameter because ulLength is not
evenly divisible by nMaxBytesPerFrame. For isoch capture, this should
always be true, but it was not enforced in the Vista 1394 driver.
I’m very disappointed. This is bad news since will probably break many
audio hardware devices / drivers combinations, including my own.
Its’s a big drawback compared to Vista/XP/W2K.
If the ulLength parameter must be divisible by nMaxBytePerFrame this
means that the name “nMaxBytePerFrame” is misleading. Its not a maximum
value any longer but in fact a constant.
This implies that sample rate matching by varying the framesize within
the hardware device is not possible within Windows 7.
Furthermore for audio applications latency is always a concern.
The new Win7 rule also introduces addional latency of 1 Frame, which
prevents optimal results by the new 1394ohci driver.
Its also means of course that you need additional hardware buffering of
1 Frame within the device. At the moment I can not guarantee if this is
possible with my device, I have to look into the firmware.
The parameter ulLength will be in most cases a power of two (measured in
samples, not in bytes!), because these values are compatible to most
audio applications. Some audio apps stop working, if other values are used.
The new rule implies that the nMaxBytesPerFrame parameter must also be a
power of two (again: measued in samples).
In other words: you are forced to waste bandwidth on the firefire bus,
even if you don’t need them.
Thanks,
/Uwe
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
uwekirst wrote:
Hello Peter,
Peter Binder schrieb:
> You are receiving a status_invalid_parameter because ulLength is not
> evenly divisible by nMaxBytesPerFrame. For isoch capture, this should
> always be true, but it was not enforced in the Vista 1394 driver.
>
>
I’m very disappointed. This is bad news since will probably break many
audio hardware devices / drivers combinations, including my own.
Its’s a big drawback compared to Vista/XP/W2K.
If the ulLength parameter must be divisible by nMaxBytePerFrame this
means that the name “nMaxBytePerFrame” is misleading. Its not a
maximum value any longer but in fact a constant.
This implies that sample rate matching by varying the framesize within
the hardware device is not possible within Windows 7.
Why? The restriction is solely on the sizes of the buffers allocated by
the driver. There’s no restriction on what the hardware actually
returns. The hardware doesn’t have to completely fill each packet.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I have also noticed that today. Sorry for my post.
The nMaxBytePerFrame parameter seems to be meaningless to ohci
controller. So it doesn’t hurt anyone to make it a little bit bigger
than (bigger than the packets transfered by the hardware).
The buffer fill mode seems to work after all, there are no empty holes
in memory, which I was afraid of.
/Uwe
Tim Roberts schrieb:
Why? The restriction is solely on the sizes of the buffers allocated by
the driver. There’s no restriction on what the hardware actually
returns. The hardware doesn’t have to completely fill each packet.
Uwe,
That is correct: there wouldn’t be any empty holes, all you’d be left with is unfilled space at the end of the buffer.
nMaxBytesPerFrame is used under certain conditions with isoch capture in buffer-fill mode. If you need to sync to a specific isoch packet (DESCRIPTOR_SYNC_ON_SY), then nMaxBytesPerFrame must be the size of the isoch packet with the sync value. I suspect it’s not applicable in your configuration, but I am aware of others that use this and in their case, nMaxBytesPerFrame must be specified correctly.
Beyond that, the 1394 bus driver doesn’t use nMaxBytesPerFrame for isoch capture in buffer-fill mode.
This check was intended for isoch capture packet-based mode and should only be enforced in that configuration (that’s the bug). In that case, we need to validate that the buffer is evenly divisible by the maximum isoch packet (nMaxBytesPerFrame) we expect to receive. If it isn’t evenly divisible, then we cannot build the DMA program for the isoch rx stream.
Another workaround for your case is to always specify an nMaxBytesPerFrame that divides evenly into the buffer length and that will have the same behavior that is present in the Vista 1394 bus driver.
I will open a bug for this issue against the new 1394 bus driver to get this fixed.
Sorry for the inconvenience.
Also, thank you for your post! Without it, we wouldn’t be able to understand what changed in the 1394 bus driver and odds are somebody else would hit the same issue at some point. As I mentioned previously, we want to get all of these issues understood and fixed in the new 1394 bus driver and any help you can provide is greatly appreciated.
Peter
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of uwekirst
Sent: Wednesday, July 08, 2009 10:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 bus driver changes Windows 7 (RC)
I have also noticed that today. Sorry for my post.
The nMaxBytePerFrame parameter seems to be meaningless to ohci
controller. So it doesn’t hurt anyone to make it a little bit bigger
than (bigger than the packets transfered by the hardware).
The buffer fill mode seems to work after all, there are no empty holes
in memory, which I was afraid of.
/Uwe
Tim Roberts schrieb:
Why? The restriction is solely on the sizes of the buffers allocated by
the driver. There’s no restriction on what the hardware actually
returns. The hardware doesn’t have to completely fill each packet.
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
Hi Peter/Uwe: Thanks for this and related further info. I am not currently
maintaining my 1394 driver of a couple of years ago, but if it comes back me
this insight into what is going on will be very useful. Also feeds forward
into new designs of course… M
>>>
----- Original Message -----
From: Peter Binder
To: Windows System Software Devs Interest List
Sent: Wednesday, July 08, 2009 3:37 PM
Subject: RE: [ntdev] 1394 bus driver changes Windows 7 (RC)
Hello Uwe/Mike,
I appreciate this feedback and I want to make one point clear: compatibility
is our biggest concern.
<<<<<