The 1394/firewire debugger connection is not worth the $32 cost of the cable
and the cost of a 1394 adapter board for the target. It’s worthless because
85% of the time it can never connect, and I do not care what I do. I’ve
started WinDbg first, and I’ve started the target first. I’ve installed the
drivers per the instructions in the documentation. I’ve set WinDbg for
channel 8 and set the target for channel 8. I’ve set WinDbg to use the
default channel and set the target to use the default channel. (O please …
of course at the same time.) I’ve set the BOOT.INI file per those
instructions and disabled the runtime 1394 driver. I’ve plugged and
unplugged, powered down and powered up till I am blue in the face, and I
still can only connect about 15% of the time compared to 100% using a
serial cable at 115.2K.
This tells me that this is the result of a “rush-to-get-it-to-market”
mentality, and adequate testing of the interface on multiple hardware
configurations was not performed. Shame on you. From about 97 to 2000 WinDbg
itself was nearly worthless. Release after release was worse than the
previous until fellas like Andre began to work on it. Then it became a
shining light. This interface harkens back to the nightmares of 1997/1998.
Just my opinion.
–
Gary G. Little
Seagate Technologies, LLC
Gary,
The 1394/firewire debugger connection is not worth
> the $32 cost of the cable and the cost of a 1394
> adapter board for the target.
works fine for me, every time (with targets running NT 5.1 and 5.2 – I
think this week they are called “XP” and “Server 2003”). Three things: I
buy Adaptec boards, on the theory that the most expensive may not be the
best, but it normally is not the worst; if a built-in 1394 chipset uses
anything but the TI chipset, I disable it and stick a TI-based board in
the box; and I disable the 1394 driver on the target so Windbg has it to
itself.
I love 1394 debugging to death. Having to debug an NT5.0 or NT4 system
is bad enough that every time I have to do that, I am considering
quitting and developing a career as a drunken street bum.
Cheers,
Felix.
Felix,
This is all well and good, and I am glad it does work for you. But it does
not work for me using a D-Link USB 2.0/Firewire Combo PCI Adapter to a Dell
Latitude laptop. Seems to me that requiring a particular 1394 chipset would
be equivalent to saying that the only serial chipset you may use is a Zilog
8530 for serial debug. The real point here is that there is NOTHING in the
docs that remotely alludes to this. I would rate the documentation of the
1394 connect at least equivalent to the serial documentation. We should be
able to get this to work reliably with that documentation, but to many of us
can’t. It’s not a documentation problem, it’s simply a very VERY buggy
interface that is NOT ready for prime time.
Server 2003 and 6.02.0013 is a multiple generation of this interface, and IT
DOES NOT WORK for anything other than “blessed” hardware, and no one knows
what the “blessed” hardware is until you’ve already bought the “unblessed”
hardware.
–
Gary G. Little
Seagate Technologies, LLC
“Felix Kasza” wrote in message news:xxxxx@windbg…
Gary,
> The 1394/firewire debugger connection is not worth
> the $32 cost of the cable and the cost of a 1394
> adapter board for the target.
works fine for me, every time (with targets running NT 5.1 and 5.2 – I
think this week they are called “XP” and “Server 2003”). Three things: I
buy Adaptec boards, on the theory that the most expensive may not be the
best, but it normally is not the worst; if a built-in 1394 chipset uses
anything but the TI chipset, I disable it and stick a TI-based board in
the box; and I disable the 1394 driver on the target so Windbg has it to
itself.
I love 1394 debugging to death. Having to debug an NT5.0 or NT4 system
is bad enough that every time I have to do that, I am considering
quitting and developing a career as a drunken street bum.
Cheers,
Felix.
I agree it’s flakey. At the least the doc should say (maybe it does, but I
haven’t checked recently) that on the target side, the 1394 should be disabled
in Device Manager. That was vital for me.
“Gary G. Little” wrote:
The 1394/firewire debugger connection is not worth the $32 cost of the cable
and the cost of a 1394 adapter board for the target. It’s worthless because
85% of the time it can never connect
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
Windows DDK MVP
Gary,
you are right, its also flakey here. But I get it to work, it just
needs some persuasion.
PART I :
I start up the host. It says:
Microsoft (R) Windows Debugger Version 6.2.0007.4
Copyright (c) Microsoft Corporation. All rights reserved.
Using 1394 for debugging
Opened \.\DBG1394_INSTANCE44
Waiting to reconnect...
Then I start up the target.
The target eventually boots up and shows the logon prompt.
The 1394 connection was not made ??? Don't panic !!!
PART II
Now I press the 'pause'(ctrl-break) button, nothing happens and then
I end the windbg host. I start it again ( ctrl-K, 1394) its says again:
Microsoft (R) Windows Debugger Version 6.2.0007.4
Copyright (c) Microsoft Corporation. All rights reserved.
Using 1394 for debugging
Opened \.\DBG1394_INSTANCE44
Waiting to reconnect...
Now I press 'pause'(ctrl-break) again. Taadaa !!
Sometimes I have to repeat PART II several times.
The funny thing is: If the connection works you can reboot the target
as often as you like, you will never loose the connection
Norbert
MOTD:"Friends help you move. Real friends help you move bodies."
I agree it's flakey. At the least the doc should say (maybe it does, but I
haven't checked recently) that on the target side, the 1394 should be disabled
in Device Manager. That was vital for me.
"Gary G. Little" wrote:
> The 1394/firewire debugger connection is not worth the $32 cost of the cable
> and the cost of a 1394 adapter board for the target. It's worthless because
> 85% of the time it can never connect
--
If replying by e-mail, please remove "nospam." from the address.
James Antognini
Windows DDK MVP
You are currently subscribed to windbg as: xxxxx@stollmann.de
To unsubscribe send a blank email to xxxxx@lists.osr.com
Gary,
Seems to me that requiring a particular 1394
> chipset would be equivalent to saying that the
> only serial chipset you may use is a Zilog 8530
> for serial debug.
Last serial chip name I know is 16550 – dates me, doesn’t it?
I agree with you that restrictions, any restrictions, should be
documented, and that the kernel debugger on the target side is picky is
a major restriction.
The only point with which I disagree is the over-broad contention that
1394 debugging is worthless – it is not. Think of it as a bonus; if it
works, all the better, if it fails, there is always the serial torture.
Say, you *did* disable the 1394 controller on the target, and there is
only one, right?
Cheers,
Felix.
Ok, I’ll rephrase, but still in light of my experience. For me, 85% of the
time 1394 debugging is worthless. 15% of the time it is priceless. :))
But … it shouldn’t be this difficult. I prefer not to bother with an
interface that requires me to stand on my head and bray like a jackass, when
I can make a jackass out of myself with out any help. :))
Yup, the targets 1394 driver is disabled in the Device Manager (Great big
ol’ red X on it).
–
Gary G. Little
Seagate Technologies, LLC
“Felix Kasza” wrote in message news:xxxxx@windbg…
>
> Gary,
>
> > Seems to me that requiring a particular 1394
> > chipset would be equivalent to saying that the
> > only serial chipset you may use is a Zilog 8530
> > for serial debug.
>
> Last serial chip name I know is 16550 – dates me, doesn’t it?
>
> I agree with you that restrictions, any restrictions, should be
> documented, and that the kernel debugger on the target side is picky is
> a major restriction.
>
> The only point with which I disagree is the over-broad contention that
> 1394 debugging is worthless – it is not. Think of it as a bonus; if it
> works, all the better, if it fails, there is always the serial torture.
>
> Say, you did disable the 1394 controller on the target, and there is
> only one, right?
>
> Cheers,
> Felix.
>
>
>
Added to my knowledge base.
Thanks.
–
Gary G. Little
Seagate Technologies, LLC
“Norbert Kawulski” wrote in message news:xxxxx@windbg…
>
> Gary,
> you are right, its also flakey here. But I get it to work, it just
> needs some persuasion.
>
> PART I :
>
> I start up the host. It says:
> -----------------
> Microsoft (R) Windows Debugger Version 6.2.0007.4
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> Using 1394 for debugging
> Opened \.\DBG1394_INSTANCE44
> Waiting to reconnect…
> ------------------
> Then I start up the target.
> The target eventually boots up and shows the logon prompt.
> The 1394 connection was not made ??? Don’t panic !!!
>
> PART II
>
> Now I press the ‘pause’(ctrl-break) button, nothing happens and then
> I end the windbg host. I start it again ( ctrl-K, 1394) its says again:
>
> -----------------
> Microsoft (R) Windows Debugger Version 6.2.0007.4
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> Using 1394 for debugging
> Opened \.\DBG1394_INSTANCE44
> Waiting to reconnect…
> ------------------
> Now I press ‘pause’(ctrl-break) again. Taadaa !!
>
> Sometimes I have to repeat PART II several times.
>
> The funny thing is: If the connection works you can reboot the target
> as often as you like, you will never loose the connection
>
> Norbert
> MOTD:“Friends help you move. Real friends help you move bodies.”
>
> > I agree it’s flakey. At the least the doc should say (maybe it does, but
I
> > haven’t checked recently) that on the target side, the 1394 should be
disabled
> > in Device Manager. That was vital for me.
>
> > “Gary G. Little” wrote:
>
> >> The 1394/firewire debugger connection is not worth the $32 cost of the
cable
> >> and the cost of a 1394 adapter board for the target. It’s worthless
because
> >> 85% of the time it can never connect
>
> > –
> > If replying by e-mail, please remove “nospam.” from the address.
>
> > James Antognini
> > Windows DDK MVP
>
>
>
> > —
> > You are currently subscribed to windbg as: xxxxx@stollmann.de
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>