1394 driver is stuck in loop. What can I do?

NTDEV
1

Hi, I am developing a 1394 device driver which is now working quite well. However as soon as I share the bus with other devices I get all sorts of weird behaviour.

For example I have a system hang which I have discovered is a loop in OHCI1394.SYS.

Can anyone suggest how to determine further what might be happening? In particular is there anyone who was involved with the 1394 bus driver reading this who might know what this loop is for?

(I’m a bit worried about it passing a test for 0ABADBEEFh - but is this a magic flag known to the 1394 writers?)

Many thanks, Mike

the infinite loop:

ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b (f74ed617)
ohci1394!OhciHandleIsochInt+0x23b:
f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
ohci1394!OhciHandleIsochInt+0x23e:
f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113 (f74ed4ef)
ohci1394!OhciHandleIsochInt+0x113:
f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
ohci1394!OhciHandleIsochInt+0x116:
f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
ohci1394!OhciHandleIsochInt+0x119:
f74ed4f5 85f6 test esi,esi
ohci1394!OhciHandleIsochInt+0x11b:
f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244 (f74ed620)
ohci1394!OhciHandleIsochInt+0x121:
f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
ohci1394!OhciHandleIsochInt+0x128:
f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244 (f74ed620)
ohci1394!OhciHandleIsochInt+0x12e:
f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
ohci1394!OhciHandleIsochInt+0x131:
f74ed50d 83e908 sub ecx,8
ohci1394!OhciHandleIsochInt+0x134:
f74ed510 3bf0 cmp esi,eax
ohci1394!OhciHandleIsochInt+0x136:
f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
ohci1394!OhciHandleIsochInt+0x139:
f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f (f74ed51b)
ohci1394!OhciHandleIsochInt+0x13f:
f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x142:
f74ed51e 85c9 test ecx,ecx
ohci1394!OhciHandleIsochInt+0x144:
f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244 (f74ed620)
ohci1394!OhciHandleIsochInt+0x14a:
f74ed526 f6471c04 test byte ptr [edi+1Ch],4
ohci1394!OhciHandleIsochInt+0x14e:
f74ed52a 8bc1 mov eax,ecx
ohci1394!OhciHandleIsochInt+0x150:
f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
ohci1394!OhciHandleIsochInt+0x154:
f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
ohci1394!OhciHandleIsochInt+0x158:
f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168 (f74ed544)
ohci1394!OhciHandleIsochInt+0x168:
f74ed544 807dff00 cmp byte ptr [ebp-1],0
ohci1394!OhciHandleIsochInt+0x16c:
f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190 (f74ed56c)
ohci1394!OhciHandleIsochInt+0x16e:
f74ed54a 837e2401 cmp dword ptr [esi+24h],1
ohci1394!OhciHandleIsochInt+0x172:
f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184 (f74ed560)
ohci1394!OhciHandleIsochInt+0x174:
f74ed550 8b4628 mov eax,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x177:
f74ed553 668b48fe mov cx,word ptr [eax-2]
ohci1394!OhciHandleIsochInt+0x17b:
f74ed557 0fb740fc movzx eax,word ptr [eax-4]
ohci1394!OhciHandleIsochInt+0x17f:
f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
ohci1394!OhciHandleIsochInt+0x182:
f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186 (f74ed562)
ohci1394!OhciHandleIsochInt+0x186:
f74ed562 6685d2 test dx,dx
ohci1394!OhciHandleIsochInt+0x189:
f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd (f74ed599)
ohci1394!OhciHandleIsochInt+0x18b:
f74ed567 6685c9 test cx,cx
ohci1394!OhciHandleIsochInt+0x18e:
f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb (f74ed597)
ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b (f74ed617)

2

Hi Folks, Why do I get the feeling that 1394 is the elephant in the room
no-one is supposed to talk about? I see reams on USB, and endless printer
driver stuff, even stuff on whether C is better than C++, but everyone goes
very quiet when 1394 is mentioned. Does anyone know the politics behind
this? Has it been quietly supressed by MS for example? Maybe all the 1394
experts have retired to the Caribbean on the profits? Thanks for any
insight… Mike

----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Monday, October 23, 2006 2:55 PM
Subject: [ntdev] 1394 driver is stuck in loop. What can I do?

Hi, I am developing a 1394 device driver which is now working quite well.
However as soon as I share the bus with other devices I get all sorts of
weird behaviour.

For example I have a system hang which I have discovered is a loop in
OHCI1394.SYS.

Can anyone suggest how to determine further what might be happening? In
particular is there anyone who was involved with the 1394 bus driver reading
this who might know what this loop is for?

(I’m a bit worried about it passing a test for 0ABADBEEFh - but is this a
magic flag known to the 1394 writers?)

Many thanks, Mike

the infinite loop:

ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)
ohci1394!OhciHandleIsochInt+0x23b:
f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
ohci1394!OhciHandleIsochInt+0x23e:
f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113
(f74ed4ef)
ohci1394!OhciHandleIsochInt+0x113:
f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
ohci1394!OhciHandleIsochInt+0x116:
f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
ohci1394!OhciHandleIsochInt+0x119:
f74ed4f5 85f6 test esi,esi
ohci1394!OhciHandleIsochInt+0x11b:
f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x121:
f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
ohci1394!OhciHandleIsochInt+0x128:
f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x12e:
f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
ohci1394!OhciHandleIsochInt+0x131:
f74ed50d 83e908 sub ecx,8
ohci1394!OhciHandleIsochInt+0x134:
f74ed510 3bf0 cmp esi,eax
ohci1394!OhciHandleIsochInt+0x136:
f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
ohci1394!OhciHandleIsochInt+0x139:
f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f
(f74ed51b)
ohci1394!OhciHandleIsochInt+0x13f:
f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x142:
f74ed51e 85c9 test ecx,ecx
ohci1394!OhciHandleIsochInt+0x144:
f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x14a:
f74ed526 f6471c04 test byte ptr [edi+1Ch],4
ohci1394!OhciHandleIsochInt+0x14e:
f74ed52a 8bc1 mov eax,ecx
ohci1394!OhciHandleIsochInt+0x150:
f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
ohci1394!OhciHandleIsochInt+0x154:
f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
ohci1394!OhciHandleIsochInt+0x158:
f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168
(f74ed544)
ohci1394!OhciHandleIsochInt+0x168:
f74ed544 807dff00 cmp byte ptr [ebp-1],0
ohci1394!OhciHandleIsochInt+0x16c:
f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190
(f74ed56c)
ohci1394!OhciHandleIsochInt+0x16e:
f74ed54a 837e2401 cmp dword ptr [esi+24h],1
ohci1394!OhciHandleIsochInt+0x172:
f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184
(f74ed560)
ohci1394!OhciHandleIsochInt+0x174:
f74ed550 8b4628 mov eax,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x177:
f74ed553 668b48fe mov cx,word ptr [eax-2]
ohci1394!OhciHandleIsochInt+0x17b:
f74ed557 0fb740fc movzx eax,word ptr [eax-4]
ohci1394!OhciHandleIsochInt+0x17f:
f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
ohci1394!OhciHandleIsochInt+0x182:
f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186
(f74ed562)
ohci1394!OhciHandleIsochInt+0x186:
f74ed562 6685d2 test dx,dx
ohci1394!OhciHandleIsochInt+0x189:
f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd
(f74ed599)
ohci1394!OhciHandleIsochInt+0x18b:
f74ed567 6685c9 test cx,cx
ohci1394!OhciHandleIsochInt+0x18e:
f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb
(f74ed597)
ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Not exactly…but you got to give somebody a little bit of tiem. I just
saw your post and barely had time to read it before I saw this. 1394 is
not that popular a bus, so the number of folks who are experts or just
plain experienced with 1394 is smaller then USB / Printers / PCI. I
for one have not had much experience with 1394 while I have had a ton
with other types of busses and that’s why I generally stay away from
1394 questions :wink:

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, October 23, 2006 9:18 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 driver is stuck in loop. What can I do?

Hi Folks, Why do I get the feeling that 1394 is the elephant in the room

no-one is supposed to talk about? I see reams on USB, and endless
printer
driver stuff, even stuff on whether C is better than C++, but everyone
goes
very quiet when 1394 is mentioned. Does anyone know the politics behind
this? Has it been quietly supressed by MS for example? Maybe all the
1394
experts have retired to the Caribbean on the profits? Thanks for any
insight… Mike

----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Monday, October 23, 2006 2:55 PM
Subject: [ntdev] 1394 driver is stuck in loop. What can I do?

Hi, I am developing a 1394 device driver which is now working quite
well.
However as soon as I share the bus with other devices I get all sorts of

weird behaviour.

For example I have a system hang which I have discovered is a loop in
OHCI1394.SYS.

Can anyone suggest how to determine further what might be happening? In
particular is there anyone who was involved with the 1394 bus driver
reading
this who might know what this loop is for?

(I’m a bit worried about it passing a test for 0ABADBEEFh - but is this
a
magic flag known to the 1394 writers?)

Many thanks, Mike

the infinite loop:

ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)
ohci1394!OhciHandleIsochInt+0x23b:
f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
ohci1394!OhciHandleIsochInt+0x23e:
f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113
(f74ed4ef)
ohci1394!OhciHandleIsochInt+0x113:
f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
ohci1394!OhciHandleIsochInt+0x116:
f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
ohci1394!OhciHandleIsochInt+0x119:
f74ed4f5 85f6 test esi,esi
ohci1394!OhciHandleIsochInt+0x11b:
f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x121:
f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
ohci1394!OhciHandleIsochInt+0x128:
f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x12e:
f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
ohci1394!OhciHandleIsochInt+0x131:
f74ed50d 83e908 sub ecx,8
ohci1394!OhciHandleIsochInt+0x134:
f74ed510 3bf0 cmp esi,eax
ohci1394!OhciHandleIsochInt+0x136:
f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
ohci1394!OhciHandleIsochInt+0x139:
f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f
(f74ed51b)
ohci1394!OhciHandleIsochInt+0x13f:
f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x142:
f74ed51e 85c9 test ecx,ecx
ohci1394!OhciHandleIsochInt+0x144:
f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x14a:
f74ed526 f6471c04 test byte ptr [edi+1Ch],4
ohci1394!OhciHandleIsochInt+0x14e:
f74ed52a 8bc1 mov eax,ecx
ohci1394!OhciHandleIsochInt+0x150:
f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
ohci1394!OhciHandleIsochInt+0x154:
f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
ohci1394!OhciHandleIsochInt+0x158:
f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168
(f74ed544)
ohci1394!OhciHandleIsochInt+0x168:
f74ed544 807dff00 cmp byte ptr [ebp-1],0
ohci1394!OhciHandleIsochInt+0x16c:
f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190
(f74ed56c)
ohci1394!OhciHandleIsochInt+0x16e:
f74ed54a 837e2401 cmp dword ptr [esi+24h],1
ohci1394!OhciHandleIsochInt+0x172:
f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184
(f74ed560)
ohci1394!OhciHandleIsochInt+0x174:
f74ed550 8b4628 mov eax,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x177:
f74ed553 668b48fe mov cx,word ptr [eax-2]
ohci1394!OhciHandleIsochInt+0x17b:
f74ed557 0fb740fc movzx eax,word ptr [eax-4]
ohci1394!OhciHandleIsochInt+0x17f:
f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
ohci1394!OhciHandleIsochInt+0x182:
f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186
(f74ed562)
ohci1394!OhciHandleIsochInt+0x186:
f74ed562 6685d2 test dx,dx
ohci1394!OhciHandleIsochInt+0x189:
f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd
(f74ed599)
ohci1394!OhciHandleIsochInt+0x18b:
f74ed567 6685c9 test cx,cx
ohci1394!OhciHandleIsochInt+0x18e:
f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb
(f74ed597)
ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Mike Kemp wrote:

Hi Folks, Why do I get the feeling that 1394 is the elephant in the
room no-one is supposed to talk about? I see reams on USB, and endless
printer driver stuff, even stuff on whether C is better than C++, but
everyone goes very quiet when 1394 is mentioned. Does anyone know the
politics behind this? Has it been quietly supressed by MS for example?
Maybe all the 1394 experts have retired to the Caribbean on the
profits? Thanks for any insight…

Apple nearly killed 1394 with their stupid patent restrictions. There
was early resistance in the hardware world, and there was early
resistance from Microsoft. As soon as USB 2.0 was announced, with
better bandwidth than 1394 v1, USB immediately became the path of least
resistance.

Technically speaking, I think USB is a better protocol and has a simpler
controller design. I did a 1394 project in 1997, and since that time,
not one of our clients has ever asked for it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Thanks Doron - it’s actually a feeling based on a number of queries I’ve
had. I suspect that my problem is that my niche - audio - has fixated on the
1394 bus. I think it is suffering from many problems stemming from lack of
documentation and poor MS support, to the point where the level of testing
stops at the “my driver works so I’m happy” without anyone considering that
more than one device may get used! I suspect that as long as a digital
camera works most of the time MS is happy! atb Mike.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, October 23, 2006 5:27 PM
Subject: RE: [ntdev] 1394 driver is stuck in loop. What can I do?

Not exactly…but you got to give somebody a little bit of tiem. I just
saw your post and barely had time to read it before I saw this. 1394 is
not that popular a bus, so the number of folks who are experts or just
plain experienced with 1394 is smaller then USB / Printers / PCI. I
for one have not had much experience with 1394 while I have had a ton
with other types of busses and that’s why I generally stay away from
1394 questions :wink:

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, October 23, 2006 9:18 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 driver is stuck in loop. What can I do?

Hi Folks, Why do I get the feeling that 1394 is the elephant in the room

no-one is supposed to talk about? I see reams on USB, and endless
printer
driver stuff, even stuff on whether C is better than C++, but everyone
goes
very quiet when 1394 is mentioned. Does anyone know the politics behind
this? Has it been quietly supressed by MS for example? Maybe all the
1394
experts have retired to the Caribbean on the profits? Thanks for any
insight… Mike

----- Original Message -----
From: Mike Kemp
To: Windows System Software Devs Interest List
Sent: Monday, October 23, 2006 2:55 PM
Subject: [ntdev] 1394 driver is stuck in loop. What can I do?

Hi, I am developing a 1394 device driver which is now working quite
well.
However as soon as I share the bus with other devices I get all sorts of

weird behaviour.

For example I have a system hang which I have discovered is a loop in
OHCI1394.SYS.

Can anyone suggest how to determine further what might be happening? In
particular is there anyone who was involved with the 1394 bus driver
reading
this who might know what this loop is for?

(I’m a bit worried about it passing a test for 0ABADBEEFh - but is this
a
magic flag known to the 1394 writers?)

Many thanks, Mike

the infinite loop:

ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)
ohci1394!OhciHandleIsochInt+0x23b:
f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
ohci1394!OhciHandleIsochInt+0x23e:
f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113
(f74ed4ef)
ohci1394!OhciHandleIsochInt+0x113:
f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
ohci1394!OhciHandleIsochInt+0x116:
f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
ohci1394!OhciHandleIsochInt+0x119:
f74ed4f5 85f6 test esi,esi
ohci1394!OhciHandleIsochInt+0x11b:
f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x121:
f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
ohci1394!OhciHandleIsochInt+0x128:
f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x12e:
f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
ohci1394!OhciHandleIsochInt+0x131:
f74ed50d 83e908 sub ecx,8
ohci1394!OhciHandleIsochInt+0x134:
f74ed510 3bf0 cmp esi,eax
ohci1394!OhciHandleIsochInt+0x136:
f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
ohci1394!OhciHandleIsochInt+0x139:
f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f
(f74ed51b)
ohci1394!OhciHandleIsochInt+0x13f:
f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x142:
f74ed51e 85c9 test ecx,ecx
ohci1394!OhciHandleIsochInt+0x144:
f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x14a:
f74ed526 f6471c04 test byte ptr [edi+1Ch],4
ohci1394!OhciHandleIsochInt+0x14e:
f74ed52a 8bc1 mov eax,ecx
ohci1394!OhciHandleIsochInt+0x150:
f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
ohci1394!OhciHandleIsochInt+0x154:
f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
ohci1394!OhciHandleIsochInt+0x158:
f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168
(f74ed544)
ohci1394!OhciHandleIsochInt+0x168:
f74ed544 807dff00 cmp byte ptr [ebp-1],0
ohci1394!OhciHandleIsochInt+0x16c:
f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190
(f74ed56c)
ohci1394!OhciHandleIsochInt+0x16e:
f74ed54a 837e2401 cmp dword ptr [esi+24h],1
ohci1394!OhciHandleIsochInt+0x172:
f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184
(f74ed560)
ohci1394!OhciHandleIsochInt+0x174:
f74ed550 8b4628 mov eax,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x177:
f74ed553 668b48fe mov cx,word ptr [eax-2]
ohci1394!OhciHandleIsochInt+0x17b:
f74ed557 0fb740fc movzx eax,word ptr [eax-4]
ohci1394!OhciHandleIsochInt+0x17f:
f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
ohci1394!OhciHandleIsochInt+0x182:
f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186
(f74ed562)
ohci1394!OhciHandleIsochInt+0x186:
f74ed562 6685d2 test dx,dx
ohci1394!OhciHandleIsochInt+0x189:
f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd
(f74ed599)
ohci1394!OhciHandleIsochInt+0x18b:
f74ed567 6685c9 test cx,cx
ohci1394!OhciHandleIsochInt+0x18e:
f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb
(f74ed597)
ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

> resistance from Microsoft. As soon as USB 2.0 was announced, with

better bandwidth than 1394 v1, USB immediately became the path of least
resistance.

1394/400MHz is faster for storage then USB 2/480MHz. Something like 27MB/s vs.
22.

Technically speaking, I think USB is a better protocol and has a simpler
controller design.

1394 is extremely complex due to being peer-to-peer - not requiring a host.
Also, its design is to encapsulate the usual PCI-style addressing via serial
wires.

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

7

Hi Tim, Thanks for the input on this. However if it seems that if MS is not
supporting 1394, how would I go about at least getting MS to release the
source for their drivers so that the rest of us can make do with an
unsupported interface. Does anyone know how to approach MS for source
listings?

Since I’ve made a number of requests here for info re 1394 and no-one will
pick up the baton, I wonder how to proceeed. Is the only option to “reverse
engineer” from the disassembly? It is a daunting task! - Mike

----- Original Message -----
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Monday, October 23, 2006 6:05 PM
Subject: Re: [ntdev] 1394 driver is stuck in loop. What can I do?

Mike Kemp wrote:

Hi Folks, Why do I get the feeling that 1394 is the elephant in the
room no-one is supposed to talk about? I see reams on USB, and endless
printer driver stuff, even stuff on whether C is better than C++, but
everyone goes very quiet when 1394 is mentioned. Does anyone know the
politics behind this? Has it been quietly supressed by MS for example?
Maybe all the 1394 experts have retired to the Caribbean on the
profits? Thanks for any insight…

Apple nearly killed 1394 with their stupid patent restrictions. There
was early resistance in the hardware world, and there was early
resistance from Microsoft. As soon as USB 2.0 was announced, with
better bandwidth than 1394 v1, USB immediately became the path of least
resistance.

Technically speaking, I think USB is a better protocol and has a simpler
controller design. I did a 1394 project in 1997, and since that time,
not one of our clients has ever asked for it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

Hi Mike,

we use the IEEE 1394 bus to control our digital cameras and to acquire
their image data. We perform isochronous listening in the so called
stream-based mode. After circumventing some problems we could put it to
work eventually. So far neither did we encounter special problems
resulting from the presence of multiple isochronous talkers at the bus
nor did we observe the endless loop in OHCI1394.sys as you describe.

Because you are dealing with audio I assume you are listening in
packet-based mode. Unfortunately I can’t give any advice with respect to
packet-based isochronous listening.

We could gain support by Microsoft some times by issuing an incident at
the MSDN support (for developers). These cases were routed via DDK
support to a guy who is responsible for 1394 support. Just send a bug
report with stack traces etc. and later on a simple test code
reproducing the problem including the necessary hardware. We asked
several times for access to the source code of the 1394 driver stack to
debug the problems by our self. The requests were always denied.

I received the impression of a certain fragility of the Windows 1394
driver stack. You have still the alternative of using one of the other
(commercial) available 1394 stacks for Windows if you neither get
reasonable support nor can solve the problem by yourself. However the
compatibility of your solution with further 3rd party 1394 components
may be affected by such a decision.

Best regards,
Volker

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Tuesday, October 24, 2006 12:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394 driver is stuck in loop. What can I do?

Hi Tim, Thanks for the input on this. However if it seems
that if MS is not supporting 1394, how would I go about at
least getting MS to release the source for their drivers so
that the rest of us can make do with an unsupported
interface. Does anyone know how to approach MS for source listings?

Since I’ve made a number of requests here for info re 1394
and no-one will pick up the baton, I wonder how to proceeed.
Is the only option to “reverse engineer” from the
disassembly? It is a daunting task! - Mike

----- Original Message -----
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Monday, October 23, 2006 6:05 PM
Subject: Re: [ntdev] 1394 driver is stuck in loop. What can I do?

Mike Kemp wrote:

> Hi Folks, Why do I get the feeling that 1394 is the elephant in the
> room no-one is supposed to talk about? I see reams on USB,
and endless
> printer driver stuff, even stuff on whether C is better
than C++, but
> everyone goes very quiet when 1394 is mentioned. Does
anyone know the
> politics behind this? Has it been quietly supressed by MS
for example?
> Maybe all the 1394 experts have retired to the Caribbean on the
> profits? Thanks for any insight…

Apple nearly killed 1394 with their stupid patent restrictions. There
was early resistance in the hardware world, and there was early
resistance from Microsoft. As soon as USB 2.0 was announced, with
better bandwidth than 1394 v1, USB immediately became the
path of least
resistance.

Technically speaking, I think USB is a better protocol and
has a simpler
controller design. I did a 1394 project in 1997, and since that time,
not one of our clients has ever asked for it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

9

Hi:

I got a 1394 device to work with Windows 2000 as a WDM driver. I varied the sonydcam to work with the box. I tested multiple 1394 devices on the bus and I had no such problem. May I suggest you check other devices with the 1394 that work sharing the bus maybe use a sniffer to look at some relevant packets with something that works. I would then look at your device with its driver that works in standalone. Look at this when you plug it in so you get a trace from the begining from your driver and from the sniffer as well. I would get a trace when you share the bus with another device, from your driver and with a sniffer. I would try a reordering of the devices on the bus as well.

Are you using a variation of the sonydcam.sys that is a sample in the DDK as well?

Does the device work with other devices on the bus in any environment?

Sorry I could help further.

William Michael Jones “Mike”

“Mike Kemp” wrote in message news:xxxxx@ntdev…
Hi, I am developing a 1394 device driver which is now working quite well. However as soon as I share the bus with other devices I get all sorts of weird behaviour.

For example I have a system hang which I have discovered is a loop in OHCI1394.SYS.

Can anyone suggest how to determine further what might be happening? In particular is there anyone who was involved with the 1394 bus driver reading this who might know what this loop is for?

(I’m a bit worried about it passing a test for 0ABADBEEFh - but is this a magic flag known to the 1394 writers?)

Many thanks, Mike

the infinite loop:

ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b (f74ed617)
ohci1394!OhciHandleIsochInt+0x23b:
f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
ohci1394!OhciHandleIsochInt+0x23e:
f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113 (f74ed4ef)
ohci1394!OhciHandleIsochInt+0x113:
f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
ohci1394!OhciHandleIsochInt+0x116:
f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
ohci1394!OhciHandleIsochInt+0x119:
f74ed4f5 85f6 test esi,esi
ohci1394!OhciHandleIsochInt+0x11b:
f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244 (f74ed620)
ohci1394!OhciHandleIsochInt+0x121:
f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
ohci1394!OhciHandleIsochInt+0x128:
f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244 (f74ed620)
ohci1394!OhciHandleIsochInt+0x12e:
f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
ohci1394!OhciHandleIsochInt+0x131:
f74ed50d 83e908 sub ecx,8
ohci1394!OhciHandleIsochInt+0x134:
f74ed510 3bf0 cmp esi,eax
ohci1394!OhciHandleIsochInt+0x136:
f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
ohci1394!OhciHandleIsochInt+0x139:
f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f (f74ed51b)
ohci1394!OhciHandleIsochInt+0x13f:
f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x142:
f74ed51e 85c9 test ecx,ecx
ohci1394!OhciHandleIsochInt+0x144:
f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244 (f74ed620)
ohci1394!OhciHandleIsochInt+0x14a:
f74ed526 f6471c04 test byte ptr [edi+1Ch],4
ohci1394!OhciHandleIsochInt+0x14e:
f74ed52a 8bc1 mov eax,ecx
ohci1394!OhciHandleIsochInt+0x150:
f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
ohci1394!OhciHandleIsochInt+0x154:
f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
ohci1394!OhciHandleIsochInt+0x158:
f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168 (f74ed544)
ohci1394!OhciHandleIsochInt+0x168:
f74ed544 807dff00 cmp byte ptr [ebp-1],0
ohci1394!OhciHandleIsochInt+0x16c:
f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190 (f74ed56c)
ohci1394!OhciHandleIsochInt+0x16e:
f74ed54a 837e2401 cmp dword ptr [esi+24h],1
ohci1394!OhciHandleIsochInt+0x172:
f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184 (f74ed560)
ohci1394!OhciHandleIsochInt+0x174:
f74ed550 8b4628 mov eax,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x177:
f74ed553 668b48fe mov cx,word ptr [eax-2]
ohci1394!OhciHandleIsochInt+0x17b:
f74ed557 0fb740fc movzx eax,word ptr [eax-4]
ohci1394!OhciHandleIsochInt+0x17f:
f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
ohci1394!OhciHandleIsochInt+0x182:
f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186 (f74ed562)
ohci1394!OhciHandleIsochInt+0x186:
f74ed562 6685d2 test dx,dx
ohci1394!OhciHandleIsochInt+0x189:
f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd (f74ed599)
ohci1394!OhciHandleIsochInt+0x18b:
f74ed567 6685c9 test cx,cx
ohci1394!OhciHandleIsochInt+0x18e:
f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb (f74ed597)
ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b (f74ed617)

10

Thanks for the various feedback on this. I have just been investigating some
issues related to whether I let my device be a bus / isochronous resources
manager, or whether I turn this off and leave it to Windows. Does anyone
have any experience of these two approaches? Is it usual for “peripheral”
devices to let themselves be bus manager or is preferable for them not to
be?

My driver is based on the DDK 1394 diag example. It does not use any higher
level sound / video stuff as we have our own format for fixed length isoch
packets that are not actually sound as far as the OS is concerned, so we
just go in at the basic 1394 level on top of the ohci1394 and 1394bus
drivers.

BTW any suggestions for a good (and not too expensive) bus sniffer? Maybe a
different PC can snoop the bus and log the packets? - Mike

----- Original Message -----
From: William Michael Jones
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, October 24, 2006 4:32 PM
Subject: Re:[ntdev] 1394 driver is stuck in loop. What can I do?

Hi:

I got a 1394 device to work with Windows 2000 as a WDM driver. I varied the
sonydcam to work with the box. I tested multiple 1394 devices on the bus and
I had no such problem. May I suggest you check other devices with the 1394
that work sharing the bus maybe use a sniffer to look at some relevant
packets with something that works. I would then look at your device with
its driver that works in standalone. Look at this when you plug it in so
you get a trace from the begining from your driver and from the sniffer as
well. I would get a trace when you share the bus with another device, from
your driver and with a sniffer. I would try a reordering of the devices on
the bus as well.

Are you using a variation of the sonydcam.sys that is a sample in the DDK as
well?

Does the device work with other devices on the bus in any environment?

Sorry I could help further.

William Michael Jones “Mike”

“Mike Kemp” wrote in message news:xxxxx@ntdev…
Hi, I am developing a 1394 device driver which is now working quite well.
However as soon as I share the bus with other devices I get all sorts of
weird behaviour.

For example I have a system hang which I have discovered is a loop in
OHCI1394.SYS.

Can anyone suggest how to determine further what might be happening? In
particular is there anyone who was involved with the 1394 bus driver reading
this who might know what this loop is for?

(I’m a bit worried about it passing a test for 0ABADBEEFh - but is this a
magic flag known to the 1394 writers?)

Many thanks, Mike

the infinite loop:

ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)
ohci1394!OhciHandleIsochInt+0x23b:
f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
ohci1394!OhciHandleIsochInt+0x23e:
f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113
(f74ed4ef)
ohci1394!OhciHandleIsochInt+0x113:
f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
ohci1394!OhciHandleIsochInt+0x116:
f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
ohci1394!OhciHandleIsochInt+0x119:
f74ed4f5 85f6 test esi,esi
ohci1394!OhciHandleIsochInt+0x11b:
f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x121:
f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
ohci1394!OhciHandleIsochInt+0x128:
f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x12e:
f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
ohci1394!OhciHandleIsochInt+0x131:
f74ed50d 83e908 sub ecx,8
ohci1394!OhciHandleIsochInt+0x134:
f74ed510 3bf0 cmp esi,eax
ohci1394!OhciHandleIsochInt+0x136:
f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
ohci1394!OhciHandleIsochInt+0x139:
f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f
(f74ed51b)
ohci1394!OhciHandleIsochInt+0x13f:
f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x142:
f74ed51e 85c9 test ecx,ecx
ohci1394!OhciHandleIsochInt+0x144:
f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244
(f74ed620)
ohci1394!OhciHandleIsochInt+0x14a:
f74ed526 f6471c04 test byte ptr [edi+1Ch],4
ohci1394!OhciHandleIsochInt+0x14e:
f74ed52a 8bc1 mov eax,ecx
ohci1394!OhciHandleIsochInt+0x150:
f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
ohci1394!OhciHandleIsochInt+0x154:
f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
ohci1394!OhciHandleIsochInt+0x158:
f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168
(f74ed544)
ohci1394!OhciHandleIsochInt+0x168:
f74ed544 807dff00 cmp byte ptr [ebp-1],0
ohci1394!OhciHandleIsochInt+0x16c:
f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190
(f74ed56c)
ohci1394!OhciHandleIsochInt+0x16e:
f74ed54a 837e2401 cmp dword ptr [esi+24h],1
ohci1394!OhciHandleIsochInt+0x172:
f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184
(f74ed560)
ohci1394!OhciHandleIsochInt+0x174:
f74ed550 8b4628 mov eax,dword ptr [esi+28h]
ohci1394!OhciHandleIsochInt+0x177:
f74ed553 668b48fe mov cx,word ptr [eax-2]
ohci1394!OhciHandleIsochInt+0x17b:
f74ed557 0fb740fc movzx eax,word ptr [eax-4]
ohci1394!OhciHandleIsochInt+0x17f:
f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
ohci1394!OhciHandleIsochInt+0x182:
f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186
(f74ed562)
ohci1394!OhciHandleIsochInt+0x186:
f74ed562 6685d2 test dx,dx
ohci1394!OhciHandleIsochInt+0x189:
f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd
(f74ed599)
ohci1394!OhciHandleIsochInt+0x18b:
f74ed567 6685c9 test cx,cx
ohci1394!OhciHandleIsochInt+0x18e:
f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb
(f74ed597)
ohci1394!OhciHandleIsochInt+0x1bb:
f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
(f74ed617)

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

11

Mike Kemp wrote:

Hi Tim, Thanks for the input on this. However if it seems that if MS
is not supporting 1394, how would I go about at least getting MS to
release the source for their drivers so that the rest of us can make
do with an unsupported interface. Does anyone know how to approach MS
for source listings?

I never said they didn’t support it. There was some early resistance,
but 1394 has certainly been an officially supported bus for many years.

Since I’ve made a number of requests here for info re 1394 and no-one
will pick up the baton, I wonder how to proceeed.

I think what you are seeing reflects a lack of experience, not a lack of
support. Lots of people are doing USB, so there are lots of real-world
stories to share. Fewer people are doing 1394, so there are fewer
people doing the sharing.

Also remember that this mailing list is NOT an official Microsoft
support channel.

Is the only option to “reverse engineer” from the disassembly? It is a
daunting task!

Have you tried the official Microsoft support channels?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

Hi Tim: Well, I’ve not tried official MS support. The thought fills me with
dread. I think its all the smart suits in the ads! If all my current options
run out, that will be the final option I think!. Thanks for the comments
though… Mike

----- Original Message -----
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Tuesday, October 24, 2006 5:44 PM
Subject: Re: [ntdev] 1394 driver is stuck in loop. What can I do?

Mike Kemp wrote:

Hi Tim, Thanks for the input on this. However if it seems that if MS
is not supporting 1394, how would I go about at least getting MS to
release the source for their drivers so that the rest of us can make
do with an unsupported interface. Does anyone know how to approach MS
for source listings?

I never said they didn’t support it. There was some early resistance,
but 1394 has certainly been an officially supported bus for many years.

Since I’ve made a number of requests here for info re 1394 and no-one
will pick up the baton, I wonder how to proceeed.

I think what you are seeing reflects a lack of experience, not a lack of
support. Lots of people are doing USB, so there are lots of real-world
stories to share. Fewer people are doing 1394, so there are fewer
people doing the sharing.

Also remember that this mailing list is NOT an official Microsoft
support channel.

Is the only option to “reverse engineer” from the disassembly? It is a
daunting task!

Have you tried the official Microsoft support channels?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

> My driver is based on the DDK 1394 diag example. It does not use any higher

1394diag is dirtily written and buggy.

Try 1394dcam/sonydcam sample instead - yes, it has some KS/stream.sys part, but
the 1394 isoch part too.

Unfortunately, the hardware itself is out of production for several years.

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

14

A good (and not too expensive) 1394 bus sniffer is FireSpy from
dapDesign, see http://www.dapdesign.com/
If you develop 1394 devices and/or device drivers you will definitely
need it.

We successfully develop 1394 drivers based on the MS bus driver for many
years. We created some sophisticated solutions, including low-latency
audio streaming. I can say that the bus driver works. Sure, there are
issues as with every Windows bus driver :wink: But, in principle the 1394
bus driver functions as described in the DDK. However, in order to fully
understand the documentation you need a deep understanding of 1394
technology.

The 1394diag sample is not a good starting point. It has lots of
problems and you will probably have to spend huge amounts of time to
create a production-quality driver based on it. Some time ago, I wrote a
review paper of the 1394diag sample. Meanwhile this might be a bit
outdated because it is based on an older DDK version. Please contact me
directly if you want to receive a copy.

In the past, 1394 developer support worked quite well, at least in my
experience. Have you tried to contact xxxxx@microsoft.com ?.

However, your problem description looks a bit weird. It seems that you
are doing something completely wrong. One would need to look into more
details to analyze the problem.

Udo

Mike Kemp wrote:

Thanks for the various feedback on this. I have just been investigating
some issues related to whether I let my device be a bus / isochronous
resources manager, or whether I turn this off and leave it to Windows.
Does anyone have any experience of these two approaches? Is it usual for
“peripheral” devices to let themselves be bus manager or is preferable
for them not to be?

My driver is based on the DDK 1394 diag example. It does not use any
higher level sound / video stuff as we have our own format for fixed
length isoch packets that are not actually sound as far as the OS is
concerned, so we just go in at the basic 1394 level on top of the
ohci1394 and 1394bus drivers.

BTW any suggestions for a good (and not too expensive) bus sniffer?
Maybe a different PC can snoop the bus and log the packets? - Mike

----- Original Message ----- From: William Michael Jones
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Tuesday, October 24, 2006 4:32 PM
Subject: Re:[ntdev] 1394 driver is stuck in loop. What can I do?

Hi:

I got a 1394 device to work with Windows 2000 as a WDM driver. I varied
the sonydcam to work with the box. I tested multiple 1394 devices on the
bus and I had no such problem. May I suggest you check other devices
with the 1394 that work sharing the bus maybe use a sniffer to look at
some relevant packets with something that works. I would then look at
your device with its driver that works in standalone. Look at this when
you plug it in so you get a trace from the begining from your driver and
from the sniffer as well. I would get a trace when you share the bus
with another device, from your driver and with a sniffer. I would try a
reordering of the devices on the bus as well.

Are you using a variation of the sonydcam.sys that is a sample in the
DDK as well?

Does the device work with other devices on the bus in any environment?

Sorry I could help further.

William Michael Jones “Mike”

“Mike Kemp” wrote in message news:xxxxx@ntdev…
> Hi, I am developing a 1394 device driver which is now working quite
> well. However as soon as I share the bus with other devices I get all
> sorts of weird behaviour.
>
> For example I have a system hang which I have discovered is a loop in
> OHCI1394.SYS.
>
> Can anyone suggest how to determine further what might be happening? In
> particular is there anyone who was involved with the 1394 bus driver
> reading this who might know what this loop is for?
>
> (I’m a bit worried about it passing a test for 0ABADBEEFh - but is this
> a magic flag known to the 1394 writers?)
>
> Many thanks, Mike
>
> the infinite loop:
>
> ohci1394!OhciHandleIsochInt+0x1bb:
> f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
> (f74ed617)
> ohci1394!OhciHandleIsochInt+0x23b:
> f74ed617 3975e8 cmp dword ptr [ebp-18h],esi
> ohci1394!OhciHandleIsochInt+0x23e:
> f74ed61a 0f85cffeffff jne ohci1394!OhciHandleIsochInt+0x113
> (f74ed4ef)
> ohci1394!OhciHandleIsochInt+0x113:
> f74ed4ef 8b45e8 mov eax,dword ptr [ebp-18h]
> ohci1394!OhciHandleIsochInt+0x116:
> f74ed4f2 8b774c mov esi,dword ptr [edi+4Ch]
> ohci1394!OhciHandleIsochInt+0x119:
> f74ed4f5 85f6 test esi,esi
> ohci1394!OhciHandleIsochInt+0x11b:
> f74ed4f7 0f8423010000 je ohci1394!OhciHandleIsochInt+0x244
> (f74ed620)
> ohci1394!OhciHandleIsochInt+0x121:
> f74ed4fd 817e10efbeadab cmp dword ptr [esi+10h],0ABADBEEFh
> ohci1394!OhciHandleIsochInt+0x128:
> f74ed504 0f8516010000 jne ohci1394!OhciHandleIsochInt+0x244
> (f74ed620)
> ohci1394!OhciHandleIsochInt+0x12e:
> f74ed50a 8b4e08 mov ecx,dword ptr [esi+8]
> ohci1394!OhciHandleIsochInt+0x131:
> f74ed50d 83e908 sub ecx,8
> ohci1394!OhciHandleIsochInt+0x134:
> f74ed510 3bf0 cmp esi,eax
> ohci1394!OhciHandleIsochInt+0x136:
> f74ed512 894f4c mov dword ptr [edi+4Ch],ecx
> ohci1394!OhciHandleIsochInt+0x139:
> f74ed515 7504 jne ohci1394!OhciHandleIsochInt+0x13f
> (f74ed51b)
> ohci1394!OhciHandleIsochInt+0x13f:
> f74ed51b 8b4e28 mov ecx,dword ptr [esi+28h]
> ohci1394!OhciHandleIsochInt+0x142:
> f74ed51e 85c9 test ecx,ecx
> ohci1394!OhciHandleIsochInt+0x144:
> f74ed520 0f84fa000000 je ohci1394!OhciHandleIsochInt+0x244
> (f74ed620)
> ohci1394!OhciHandleIsochInt+0x14a:
> f74ed526 f6471c04 test byte ptr [edi+1Ch],4
> ohci1394!OhciHandleIsochInt+0x14e:
> f74ed52a 8bc1 mov eax,ecx
> ohci1394!OhciHandleIsochInt+0x150:
> f74ed52c 668b500e mov dx,word ptr [eax+0Eh]
> ohci1394!OhciHandleIsochInt+0x154:
> f74ed530 0fb7580c movzx ebx,word ptr [eax+0Ch]
> ohci1394!OhciHandleIsochInt+0x158:
> f74ed534 740e je ohci1394!OhciHandleIsochInt+0x168
> (f74ed544)
> ohci1394!OhciHandleIsochInt+0x168:
> f74ed544 807dff00 cmp byte ptr [ebp-1],0
> ohci1394!OhciHandleIsochInt+0x16c:
> f74ed548 7422 je ohci1394!OhciHandleIsochInt+0x190
> (f74ed56c)
> ohci1394!OhciHandleIsochInt+0x16e:
> f74ed54a 837e2401 cmp dword ptr [esi+24h],1
> ohci1394!OhciHandleIsochInt+0x172:
> f74ed54e 7610 jbe ohci1394!OhciHandleIsochInt+0x184
> (f74ed560)
> ohci1394!OhciHandleIsochInt+0x174:
> f74ed550 8b4628 mov eax,dword ptr [esi+28h]
> ohci1394!OhciHandleIsochInt+0x177:
> f74ed553 668b48fe mov cx,word ptr [eax-2]
> ohci1394!OhciHandleIsochInt+0x17b:
> f74ed557 0fb740fc movzx eax,word ptr [eax-4]
> ohci1394!OhciHandleIsochInt+0x17f:
> f74ed55b 8945e4 mov dword ptr [ebp-1Ch],eax
> ohci1394!OhciHandleIsochInt+0x182:
> f74ed55e eb02 jmp ohci1394!OhciHandleIsochInt+0x186
> (f74ed562)
> ohci1394!OhciHandleIsochInt+0x186:
> f74ed562 6685d2 test dx,dx
> ohci1394!OhciHandleIsochInt+0x189:
> f74ed565 7532 jne ohci1394!OhciHandleIsochInt+0x1bd
> (f74ed599)
> ohci1394!OhciHandleIsochInt+0x18b:
> f74ed567 6685c9 test cx,cx
> ohci1394!OhciHandleIsochInt+0x18e:
> f74ed56a eb2b jmp ohci1394!OhciHandleIsochInt+0x1bb
> (f74ed597)
> ohci1394!OhciHandleIsochInt+0x1bb:
> f74ed597 747e je ohci1394!OhciHandleIsochInt+0x23b
> (f74ed617)
>
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

15

Hello Udo,
did you also have a bus driver issue list ?
That would be interesting for me too. As mentioned earlier - docs are rare …

BTW: I created an (async-only) 1394 KMDF driver last time.
And yes - I made the mistake using the ‘official’ 1394 driver example as starting point and meanwhile I re-wrote almost everything :frowning:

16

Thanks all, useful stuff. You’re not kidding about 1394diag being a heap of
****. I’ve rewritten almost everything.

BTW All my problems revolve around isoch (and only when other devices are
present), the async has always been pretty robust.

I’ll take a look at the 1394dcam/sonydcam sample - sounds like a useful tip
for a reference (thx Maxim)…

Anyone pick up on my question about whether enabling isoch/bus manager
functionalty in my device is advisable? I assume this is not common but I
started with a peer to peer architecture for my devices so it got
implemented. However I see that windows is not correctly subtracting my
allocated bandwidth from the max - it stays put at (presumably) maximum,
though this varies from instantiation to instantiation.

However when I disable this I sometimes get no isoch, suggesting WIndows is
not offering to be bus manager. I’ve also seen this behaviour some time ago
when developing our device firmware.

  • Mike

----- Original Message -----
From: Hartmut.Schaefer@HS2.de
To: Windows System Software Devs Interest List
Sent: Wednesday, October 25, 2006 12:55 AM
Subject: RE:[ntdev] 1394 driver is stuck in loop. What can I do?

Hello Udo,
did you also have a bus driver issue list ?
That would be interesting for me too. As mentioned earlier - docs are rare
…

BTW: I created an (async-only) 1394 KMDF driver last time.
And yes - I made the mistake using the ‘official’ 1394 driver example as
starting point and meanwhile I re-wrote almost everything :frowning:

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

17

That you experience problems with isoch streams if there are multiple
devices on the bus is quite unusual. The only reason I could imagine is
that your IRM behaves wrong an and does not handle channel allocation
correctly. So one channel could be assigned to more than one device
which of course will produce unforeseeable results.

According to my knowledge the MS bus driver implements IRM correctly and
always offers IRM capability. So it is advisable to let the PC be the
IRM. You are not required to expose BM and IRM capability on your device.

You should definitely use a bus sniffer to analyze these problems
further. With a sniffer it would be easy to find out what is going wrong.

Udo

Mike Kemp wrote:

Thanks all, useful stuff. You’re not kidding about 1394diag being a heap
of ****. I’ve rewritten almost everything.

BTW All my problems revolve around isoch (and only when other devices
are present), the async has always been pretty robust.

I’ll take a look at the 1394dcam/sonydcam sample - sounds like a useful
tip for a reference (thx Maxim)…

Anyone pick up on my question about whether enabling isoch/bus manager
functionalty in my device is advisable? I assume this is not common but
I started with a peer to peer architecture for my devices so it got
implemented. However I see that windows is not correctly subtracting my
allocated bandwidth from the max - it stays put at (presumably) maximum,
though this varies from instantiation to instantiation.

However when I disable this I sometimes get no isoch, suggesting WIndows
is not offering to be bus manager. I’ve also seen this behaviour some
time ago when developing our device firmware.

  • Mike

----- Original Message ----- From: Hartmut.Schaefer@HS2.de
To: Windows System Software Devs Interest List
Sent: Wednesday, October 25, 2006 12:55 AM
Subject: RE:[ntdev] 1394 driver is stuck in loop. What can I do?

Hello Udo,
did you also have a bus driver issue list ?
That would be interesting for me too. As mentioned earlier - docs are
rare …

BTW: I created an (async-only) 1394 KMDF driver last time.
And yes - I made the mistake using the ‘official’ 1394 driver example as
starting point and meanwhile I re-wrote almost everything :frowning:

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer