I will second Tony’s advice. The majority of cases that I’ve seen all
seem to be fixed by swapping out cards. An even more interesting
scenario I’ve seen:
- Machine A with 1394 card A connected to Machine B with 1394 card B has
problems
- Simply swapping the cards (Machine A with 1394 card B connected to
Machine B with 1394 card A) works perfectly
My office has about 4 machines connected and working perfectly, all of
them happen to be TI cards as well. Check out your ctrl+d output spew;
if there are errors, this tends to be a pretty good clue.
Some other useful info:
- You don’t need to disable the 1394 adapter on the target machine with
newer targets (XP SP2, Server 2003 SP1)
- I don’t think you can have 2 1394 cards in a machine and do kernel
debugging with the second card
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, August 03, 2005 11:45 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Slow 1394 debugging
We have observed this behavior before; I saw your initial note on this
and was trying to collect additional information about the specifics -
we’re in the process now of testing a variety of 1394 boards to see if
we can find one that works well with WinDBG so that we can offer it in
the OSR Online store.
The bottom line seems to be that the behavior depends very much upon the
specific chipset used in the adapter; the off-the-cuff information here
is that the TI chipsets do particularly well (something about FIFO
depths in the chipset itself…) So check your chipsets, see if you can
find some add-on adapter that uses the same chipset as that blazingly
fast laptop…
This is of course assuming you’ve done the recommended thing about
disabling the 1394 controller on the target so that it is only used by
the debugger.
As machines show up with more memory, the 1394 and USB interfaces are
going to be more important for debugging just because of their raw speed
advantage (try !irpfind on an 8GB XP workstation sometime when debugging
across a serial link…)
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeremy Sherrill
Sent: Wednesday, August 03, 2005 1:30 PM
To: Kernel Debugging Interest List
Subject: [windbg] Slow 1394 debugging
I have multiple Windows XP SP2 target systems and a single host
system. I connect to each of the targets via 1394. I disable the
1394 host controller on all targets. The problem is that on all but
one of my targets, the debugging connection is painfully slow, about
the same as serial except that driver files are transferred very
quickly (compared to serial) during driver replacement (via the driver
replacement mapping mechanism). Two things are slow: stepping through
code and transferring debug messages (displayed via DbgPrint on the
target).
I have one target system, a laptop, that is blazing fast in comparison
to all of the others. I would say that the debug messages are
transmitted at apx. 20 times the speed of the slower systems. The
debugger is also very responsive when stepping through code on the one
fast target.
Has anyone experienced this behavior? It feels to me like it has
something to do with the hardware. All of these systems have 1394
built into the motherboard, but I’m not a hardware guru. I’m sure
there is a difference, but I cannot tell what it is.
Thanks in advance,
Jeremy
You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com