You are 100% correct. The old style symlinks (XP Gold) will display as
\.\DBG1394_CHANNEL14 and the newer style (XP SP1 and above) will
display as \.\DBG1394_INSTANCE14.
I thought I remembered either the debugger parameter or the OS boot.ini
parameter changing from instance= to channel= but I was wrong. In
reality the debugger will try both symlinks just to be safe - from a
user perspective there is no need to reference “instance” anywhere. So
everywhere the channel is passed as a parameter – to the debugger or to
the OS via boot.ini – you use 1394:channel= and /channel=. If the
newer instance symlink is required the debugger will try that and make
the connection. The OS just knows about /channel as a parameter and
will do the right thing. There is no /instance for boot.ini (and never
was – again, I just got the history confused).
The recommendation from the 1394 debug driver developer here has been
that the 1394 bus host controller on the target be disabled. This
is because the boot loader will identify the 1394 controller whether or
not it is enabled – the detection is done way early in the boot
process. He has never suggested disabling the 1394 Network adapter on
host or target. Again, if anyone is finding that 1394 debugging is not
as reliable when the 1394 Network Adapter is enabled, please let us
know. And I apologize for the confusion.
-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Friday, February 14, 2003 1:22 PM
To: Kernel Debugging Interest List
Subject: [windbg] Re: 1394 Debugging…
From my post to news:microsoft.public.windbg on 10/10/2002, specifically
referring to 1394 debugging XP SP1:
I see from my windbg window that it’s opening \.\DBG1394_INSTANCE14
I’ve never manually changed that, so if it was previously using
\.\DBG1394_CHANNEL14, I don’t know when it changed. Here on my host,
Walter Oney’s Device Object Viewer shows me that I have
Dbg1394_Channel00-62, all created by 1394VDBG, which is 1394dbg1.sys,
and Dbg1394_Instance00-62, all created by 1394DBG, which is
1394dbg2.sys. Notice the V in the name of the first driver.
Device manager shows me that the “1394 Windows XP Debug Driver” is
1394dbg1.sys, and the “1394 Windows .NET Debug Driver” is 1394dbg2.sys.
So it looks like SP1 uses the .NET driver.
There’s a lot more discussion around that time that INSTANCE is the
symlink for .NET, and CHANNEL is the symlink for XP Gold.
Respectfully, David, I think you have it backward. Do please show me if
I’m still confused…
I was referring to the HBA on the host being a necessary ingredient, not
the target. Though I’ve never disabled the target HBA, just the 1394
network adapter on both ends. When I started up my 1394 connection, I
had a 1394 disk plugged into the target HBA, so I didn’t want to disable
it in any case. Since then, I’ve removed the disk, but I never changed
the setup. Since I don’t need the target HBA anymore, it sure can’t hurt
to disable it, so I’ll do that. Maybe that will solve the problem that
I, and others, have had where the connection “breaks” once in a while,
and physically disconnecting and reconnecting the cable resolves it.
Phil
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
“David Holcomb” wrote in message
news:xxxxx@windbg…
Just to be clear, /channel is the new style 1394 protocol mnemonic used
for XP SP1 and above.
XP Gold used the instance protocol.
Phil’s suggestion to make sure there are no other 1394 devices plugged
into the target is a good one. You might be interested to know that in
our test lab we use 1394 hubs so that one host can debug multiple 1394
targets. But those targets never have any other 1394 devices attached.
But it is the 1394 bus host controller that needs to be disabled, not
the 1394 network adapter. If you are finding that 1394 debugging is not
working without disabling the 1394 network adapter on one or both ends,
please share your experience.
-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Friday, February 14, 2003 12:06 PM
To: Kernel Debugging Interest List
Subject: [windbg] Re: 1394 Debugging…
wrote in message news:xxxxx@windbg…
>
> Hello All,
>
> I guess many people might have asked this question so please bear with
> me and help me do this right…
>
> I am trying to debug via 1394 and it is not working. Here is my setup.
>
> 1. Target System : WinXP SP1. AMD 1.0Ghz desktop.
> 2. Host System : WinXP SP1. P III 1.0 Ghz Laptop.
> 3. WinDBG 6.1.0017.2 latest version.
> 4. Boot.ini :
> multi(0)disk(0)rdisk(0)partition(1)\windows=“Microsoft Windows
> XP(1394)” /fastdetect /debugport=1394 /channel=5
This is correct.
> 5. WinDBG command line
> “C:\Program Files\Debugging Tools for Windows\windbg.exe” -b -k
> 1394:channel=5
Here is your problem (I think). To talk to an XP RTM target, you use
CHANNEL on the host. To talk to an XP SP1 target, you use INSTANCE. At
least, that is how my SP1 - SP1 setup is. If I’m wrong, I’m sure
someone will tell me. You might try setting up your kernel-mode session
from the GUI by not passing any command line switches, just to see if
that helps.
> 6. I have system environment variables set to
> _NT_DEBUG_BUS = 1394
> _NT_DEBUG_1394_CHANNEL = 5. Should i have to set these in Target
> system as well ?
They are irrelevant, because of your command line switches. And
especially for the target, as the environment isn’t available to the
kernel. However, if they are set, and you start windbg without any
command line switches, it will attempt to hook up using these, so unset
them before you try to connect using the GUI.
> 7. I have disabled the 1394 Net Adapter(Under Network Adapters)in the
> Target system. I tried disabling it in Host system also and it didn’t
> work. Should i have to disable the IEEE 1394 Bus Host Controllers in
> Device Manager ?
If you disable the HBA, debugging won’t work. But disabling the net
adapters at both ends seems to provide a little more stability. It
also
seems to help the stability to not have anything else (disks, cameras,
scanners) plugged into the 1394 bus you are using for debugging.
> 8. My laptop has a 4-pin firewire port and hence i am using 6-4 pin
> Firewire cable. Is that ok ?
I don’t know of any reason why it wouldn’t work.
Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com