No connect to Target over 1394

WINDBG
1

My target is 2k8 x64.
It has 3-port Adaptec 4300D add on 1394 card with 3 ports.
It shows up as NEC OHCI complaint IEEE 1394 Host controller with yellow bang. But has driver loaded for it in device manager (1394bus.sys, ohci1394.sys. It shows up with yellow bang on other machien also. but works well as windbg target etc)

My host is XP/32, it has latest windbg installed and all the 1394 controller stuff set properly (It connect to other tragets well. Those targets have intergarted 1394 ports).

I am not able to connect to this target. Another developer with the same add-on card is able to connect to it etc.

>
My host says this is windbg
"
Microsoft (R) Windows Debugger Version 6.10.0003.233 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Using 1394 for debugging
Checking 1394 debug driver version.
Opened \.\DBG1394_CHANNEL12
Waiting to reconnect…
Wrote 0 of 1 bytes of the breakin packet.
Failed to write breakin packet to target. Win32 error 0n2
WARNING: The HOST cannot communicate with the TARGET!"

> Below are bcdedit cmds i used on the target to clone a 1394 debug stuff

"
******* Run CMD prompt as adminstrator - Right click etc…************
bcdedit /copy {current} /d “CH12”

> The entry… to {xxx}.
bcdedit /debug {xxx} ON

bcdedit /dbgsettings 1394 CHANNEL:12
bcdedit /dbgsettings

Bcdedit.exe -set TESTSIGNING ON
"

>
My target bcdedit ouput is below. Please can some oen pointg out the things I am missing here

****************
C:\Windows\System32>bcdedit /dbgsettings
debugtype 1394
channel 12

C:\Windows\System32>bcdedit

Windows Boot Manager

identifier {bootmgr}
device partition=D:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
displayorder {current}
{default}
{5a35482c-ec1c-11dd-ab54-001ec9e4f38e}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader

identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description CH12
locale en-US
inherit {bootloadersettings}
testsigning Yes
osdevice partition=C:
systemroot \Windows
resumeobject {c3b850a3-eda1-11dd-9229-abf2a76d672b}
nx OptOut
debug Yes

Windows Boot Loader

identifier {default}
device partition=C:
path \Windows\system32\winload.exe
description Microsoft Windows Server 2008
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {c3b850a3-eda1-11dd-9229-abf2a76d672b}
nx OptOut

Windows Boot Loader

identifier {5a35482c-ec1c-11dd-ab54-001ec9e4f38e}
device partition=C:
path \Windows\system32\winload.exe
description 1394 CH:12
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {c3b850a3-eda1-11dd-9229-abf2a76d672b}
nx OptOut
debug Yes
********************8

2

Unfortunately, that error message doesn’t mean that there is a ‘problem’
in and of itself, much like the case of the ‘yellow bang.’ It seems
like it is much more common with the 6.10.3.233 drop, but if my memory
serves me correctly, it was there in 6.9.3.113 as well.

I’m not saying that this is your problem (I doubt it is), but the first
thing I would try short of getting some other advice is to set the debug
settings for the specific configuration ‘CH12,’ rather than rely on the
global ones /dbgsettings:

bcdedit /set {XXX} debugtype 1394
bcdedit /set {XXX} channel 12
bcdedit /set {XXX} debug on

Also, what’s your windbg command line? It appears to be fine from the
output, but whether you’re using/not using -b/-d might matter.

Good luck,

mm

xxxxx@yahoo.com wrote:

My target is 2k8 x64.
It has 3-port Adaptec 4300D add on 1394 card with 3 ports.
It shows up as NEC OHCI complaint IEEE 1394 Host controller with yellow bang. But has driver loaded for it in device manager (1394bus.sys, ohci1394.sys. It shows up with yellow bang on other machien also. but works well as windbg target etc)

My host is XP/32, it has latest windbg installed and all the 1394 controller stuff set properly (It connect to other tragets well. Those targets have intergarted 1394 ports).

I am not able to connect to this target. Another developer with the same add-on card is able to connect to it etc.

My host says this is windbg
"
Microsoft (R) Windows Debugger Version 6.10.0003.233 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Using 1394 for debugging
Checking 1394 debug driver version.
Opened \.\DBG1394_CHANNEL12
Waiting to reconnect…
Wrote 0 of 1 bytes of the breakin packet.
Failed to write breakin packet to target. Win32 error 0n2
WARNING: The HOST cannot communicate with the TARGET!"

>> Below are bcdedit cmds i used on the target to clone a 1394 debug stuff

"
******* Run CMD prompt as adminstrator - Right click etc…************
bcdedit /copy {current} /d “CH12”
>> The entry… to {xxx}.
bcdedit /debug {xxx} ON

bcdedit /dbgsettings 1394 CHANNEL:12
bcdedit /dbgsettings

Bcdedit.exe -set TESTSIGNING ON
"

My target bcdedit ouput is below. Please can some oen pointg out the things I am missing here

****************
C:\Windows\System32>bcdedit /dbgsettings
debugtype 1394
channel 12

C:\Windows\System32>bcdedit

Windows Boot Manager

identifier {bootmgr}
device partition=D:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
displayorder {current}
{default}
{5a35482c-ec1c-11dd-ab54-001ec9e4f38e}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader

identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description CH12
locale en-US
inherit {bootloadersettings}
testsigning Yes
osdevice partition=C:
systemroot \Windows
resumeobject {c3b850a3-eda1-11dd-9229-abf2a76d672b}
nx OptOut
debug Yes

Windows Boot Loader

identifier {default}
device partition=C:
path \Windows\system32\winload.exe
description Microsoft Windows Server 2008
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {c3b850a3-eda1-11dd-9229-abf2a76d672b}
nx OptOut

Windows Boot Loader

identifier {5a35482c-ec1c-11dd-ab54-001ec9e4f38e}
device partition=C:
path \Windows\system32\winload.exe
description 1394 CH:12
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {c3b850a3-eda1-11dd-9229-abf2a76d672b}
nx OptOut
debug Yes
********************8

3

MM

Thanks for ptrs

>Also, what’s your windbg command line? It appears to be fine from the
output, but whether you’re using/not using -b/-d might matter.

I just have below shortcut on dtop.
After windbg is launched I just select 1394 debuuging with the correct channel#.

“C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe” -c “.symopt-0x4” -QSY

>Also, what’s your windbg command line?
I do not have -b/-d cmdline options.
But i just break into once I see the target is up and etc…

>
I tried entyry sepcific settinsg you suggested, still happens

thanks

4

Lacking any better advice, given that 6.10.3.233 has already exhibited a
number of problems in some (still somewhat unspecified) circumstances
that are pretty much deal breakers, and that you don’t appear to have
anything obviously incorrect in your connection settings or hardware, I
would really consider uninstalling 6.10.3233 and using 6.9.3.133.

All the benefits that 6.10.3.233 purports to offer seem (judging by
relnotes.txt) to involve a new 1394 driver that is incompatible with
previous releases; it also has a long list of installation issues (see
relnotes.txt), and in addition, some of the problems (like it
mysteriously disappearing) affect serial (at least) as well, so it seems
pretty reasonable to wonder if 6.10.3.233 is DOA, or at least not the
more likely profitable path down which to first procede.

That being said, if you go the uninstall route, if it still doesn’t
work, be sure to read the relnotes.txt, because my guess would be that
the new driver might very well hang around.

Good luck,

mm

xxxxx@yahoo.com wrote:

MM

Thanks for ptrs

>> Also, what’s your windbg command line? It appears to be fine from the
output, but whether you’re using/not using -b/-d might matter.

I just have below shortcut on dtop.
After windbg is launched I just select 1394 debuuging with the correct channel#.

“C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe” -c “.symopt-0x4” -QSY

>> Also, what’s your windbg command line?
I do not have -b/-d cmdline options.
But i just break into once I see the target is up and etc…

I tried entyry sepcific settinsg you suggested, still happens

thanks

5

O.k. this is what happened (a long story), host problem…

I have a 8510w host, it has air intake at the bottom, it smoked out (literally smell all over etc…), but I never doubted it and rather was looking at my racks etc where i was swapping 1394 cards for debug…

when i took teh host to other system where same 1394 was working… it also failed… remembering that my hw radio kill also failed… i suspected the host and replaced teh shell and its tarted workinge tc :-)… huh…