Hi guys,
At last I resolved a problem with IEEE 1394 controllers and cables. For
that I had to buy a new IEEE 1394 controller with at least one 4-pin
connector on it because I couldn’t simply connect two IEEE 1394
controllers (I tried some different controllers) via 6-to-6 pins cable.
Also I tested several different cables but none of them allowed to even
establish a network connection.
But now I have another problem. The thing is that speed of debug output
is quite low, just as I would use debugging via COM ports. Earlier I
thought that the debugging over IEEE 1394 would be much faster. Of
course, response time of WinDBG became a little bit better, but the
debug output speed makes me really sad… Maybe there’s some hidden
options for IEEE 1394 debug connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be correlated with
MP vs. UP targets. So far, in the very limited number of test systems
we’ve looked at here, all the MP systems are slow, and all the UP systems
are fast.
Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is some cause for it
to stop scrolling.
There may be something obvious that we are overlooking, but that’s the
symptoms we’ve seen.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Konstantin
Manurin
om> “Kernel Debugging Interest List”
Sent by:
bounce-257250-683 cc
xxxxx@lists.osr.com
No Phone Info Subject
Available [windbg] Low speed of debug output
while debugging over IEEE 1394
07/24/2006 11:56
AM
Please respond to
“Kernel Debugging
Interest List”
.com>
Hi guys,
At last I resolved a problem with IEEE 1394 controllers and cables. For
that I had to buy a new IEEE 1394 controller with at least one 4-pin
connector on it because I couldn’t simply connect two IEEE 1394 controllers
(I tried some different controllers) via 6-to-6 pins cable. Also I tested
several different cables but none of them allowed to even establish a
network connection.
But now I have another problem. The thing is that speed of debug output is
quite low, just as I would use debugging via COM ports. Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of course, response
time of WinDBG became a little bit better, but the debug output speed makes
me really sad… Maybe there’s some hidden options for IEEE 1394 debug
connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
—
You are currently subscribed to windbg as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Philip,
Thank you very much for your quick and quite exact advice. That’s
indeed the case! I tested my target machine with /onecpu switch in the
boot.ini file and debug output strings were appearing on my host
machine several times (exactly several) faster than on the same target
machine with MP configuration. Maybe this issue of low debug output
speed on MP systems relates to extra synchronization? What can
Microsoft gurus say about this?
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be correlated with
MP vs. UP targets. So far, in the very limited number of test systems
we’ve looked at here, all the MP systems are slow, and all the UP systems
are fast.Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is some cause for it
to stop scrolling.There may be something obvious that we are overlooking, but that’s the
symptoms we’ve seen.Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842Konstantin
Manurin
om>“Kernel Debugging Interest List”
Sent by:
bounce-257250-683 cc
xxxxx@lists.osr.com
No Phone Info Subject
Available [windbg] Low speed of debug output
while debugging over IEEE 139407/24/2006 11:56
AMPlease respond to
“Kernel Debugging
Interest List”
.com>Hi guys,
At last I resolved a problem with IEEE 1394 controllers and cables. For
that I had to buy a new IEEE 1394 controller with at least one 4-pin
connector on it because I couldn’t simply connect two IEEE 1394 controllers
(I tried some different controllers) via 6-to-6 pins cable. Also I tested
several different cables but none of them allowed to even establish a
network connection.But now I have another problem. The thing is that speed of debug output is
quite low, just as I would use debugging via COM ports. Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of course, response
time of WinDBG became a little bit better, but the debug output speed makes
me really sad… Maybe there’s some hidden options for IEEE 1394 debug
connections? Or perhaps I’m wrong?Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
You are currently subscribed to windbg as:xxxxx@seagate.com
To unsubscribe send a blank email toxxxxx@lists.osr.com
There is significantly more synchronization overhead for kd mode on MP systems because all processors must be paused. This results in the initiating processor sending IPIs to all other processors and everything waiting until all processors have been idled. On resumption of execution all processors must be restarted. Idling all processors for kd mode is unavoidable as communication with the host must be synchronized.
I don’t have any firm figures for how much overhead this synchronization costs. I would guess that it’s less than a millisecond, so I wouldn’t think it would explain things being so slow, but I guess it’s possible.
From: xxxxx@lists.osr.com on behalf of Konstantin Manurin
Sent: Tue 7/25/2006 4:22 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Low speed of debug output while debugging over IEEE 1394
Philip,
Thank you very much for your quick and quite exact advice. That’s indeed the case! I tested my target machine with /onecpu switch in the boot.ini file and debug output strings were appearing on my host machine several times (exactly several) faster than on the same target machine with MP configuration. Maybe this issue of low debug output speed on MP systems relates to extra synchronization? What can Microsoft gurus say about this?
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be correlated with
MP vs. UP targets. So far, in the very limited number of test systems
we’ve looked at here, all the MP systems are slow, and all the UP systems
are fast.
Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is some cause for it
to stop scrolling.
There may be something obvious that we are overlooking, but that’s the
symptoms we’ve seen.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Konstantin
Manurin
om> mailto:xxxxx “Kernel Debugging Interest List”
Sent by: mailto:xxxxx
bounce-257250-683 cc
xxxxx@lists.osr.com
No Phone Info Subject
Available [windbg] Low speed of debug output
while debugging over IEEE 1394
07/24/2006 11:56
AM
Please respond to
“Kernel Debugging
Interest List”
.com> mailto:xxxxx
Hi guys,
At last I resolved a problem with IEEE 1394 controllers and cables. For
that I had to buy a new IEEE 1394 controller with at least one 4-pin
connector on it because I couldn’t simply connect two IEEE 1394 controllers
(I tried some different controllers) via 6-to-6 pins cable. Also I tested
several different cables but none of them allowed to even establish a
network connection.
But now I have another problem. The thing is that speed of debug output is
quite low, just as I would use debugging via COM ports. Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of course, response
time of WinDBG became a little bit better, but the debug output speed makes
me really sad… Maybe there’s some hidden options for IEEE 1394 debug
connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
—
You are currently subscribed to windbg as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Drew,
Why would they all need to be paused? Why not just use a highest-level
spinlock, such as the one in the InterlockedList routines discussed last
week? I’m sure I’m missing something, but it seems like DbgPrint() is an
ideal place to use an in-stack queued spinlock, and you don’t need to shoot
down the other CPUs for that…
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Drew Bliss”
osoft.com> To
Sent by: “Kernel Debugging Interest List”
bounce-257370-683
xxxxx@lists.osr.com cc
No Phone Info
Available Subject
RE: [windbg] Low speed of debug
output while debugging over IEEE
07/25/2006 10:59 1394
AM
Please respond to
“Kernel Debugging
Interest List”
.com>
There is significantly more synchronization overhead for kd mode on MP
systems because all processors must be paused. This results in the
initiating processor sending IPIs to all other processors and everything
waiting until all processors have been idled. On resumption of execution
all processors must be restarted. Idling all processors for kd mode is
unavoidable as communication with the host must be synchronized.
I don’t have any firm figures for how much overhead this synchronization
costs. I would guess that it’s less than a millisecond, so I wouldn’t
think it would explain things being so slow, but I guess it’s possible.
________________________________
From: xxxxx@lists.osr.com on behalf of Konstantin Manurin
Sent: Tue 7/25/2006 4:22 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Low speed of debug output while debugging over IEEE
1394
Philip,
Thank you very much for your quick and quite exact advice. That’s indeed
the case! I tested my target machine with /onecpu switch in the boot.ini
file and debug output strings were appearing on my host machine several
times (exactly several) faster than on the same target machine with MP
configuration. Maybe this issue of low debug output speed on MP systems
relates to extra synchronization? What can Microsoft gurus say about this?
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be
correlated with
MP vs. UP targets. So far, in the very limited number of test
systems
we’ve looked at here, all the MP systems are slow, and all the
UP systems
are fast.
Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is some
cause for it
to stop scrolling.
There may be something obvious that we are overlooking, but
that’s the
symptoms we’ve seen.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Konstantin
Manurin
To
om> mailto:xxxxx
“Kernel Debugging Interest List”
Sent by:
mailto:xxxxx
bounce-257250-683
cc
xxxxx@lists.osr.com
No Phone Info
Subject
Available [windbg] Low speed of
debug output
while debugging over
IEEE 1394
07/24/2006 11:56
AM
Please respond to
“Kernel Debugging
Interest List”
.com> mailto:xxxxx
Hi guys,
At last I resolved a problem with IEEE 1394 controllers and
cables. For
that I had to buy a new IEEE 1394 controller with at least one
4-pin
connector on it because I couldn’t simply connect two IEEE
1394 controllers
(I tried some different controllers) via 6-to-6 pins cable.
Also I tested
several different cables but none of them allowed to even
establish a
network connection.
But now I have another problem. The thing is that speed of
debug output is
quite low, just as I would use debugging via COM ports.
Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of
course, response
time of WinDBG became a little bit better, but the debug
output speed makes
me really sad… Maybe there’s some hidden options for IEEE
1394 debug
connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
—
You are currently subscribed to windbg as:
xxxxx@seagate.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Processors are stopped so that debugging can be done across all
processors. For example, switching processors when broken-in requires
that all processors are idle and ready to become the primary debugging
processor. There’s also global data that needs synchronization
protection.
You could certainly imagine more complicated locking schemes, such as
using different kinds of locks depending on the kind of communication or
even more complicated interlocks, but no such kernel changes are planned
due to the risk of subtle bugs.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, July 26, 2006 9:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Low speed of debug output while debugging over
IEEE 1394
Drew,
Why would they all need to be paused? Why not just use a highest-level
spinlock, such as the one in the InterlockedList routines discussed last
week? I’m sure I’m missing something, but it seems like DbgPrint() is
an ideal place to use an in-stack queued spinlock, and you don’t need to
shoot down the other CPUs for that…
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Drew Bliss”
osoft.com>
To
Sent by: “Kernel Debugging Interest List”
bounce-257370-683
xxxxx@lists.osr.com
cc
No Phone Info
Available
Subject
RE: [windbg] Low speed of debug
output while debugging over IEEE
07/25/2006 10:59 1394
AM
Please respond to
“Kernel Debugging
Interest List”
.com>
There is significantly more synchronization overhead for kd mode on MP
systems because all processors must be paused. This results in the
initiating processor sending IPIs to all other processors and everything
waiting until all processors have been idled. On resumption of
execution all processors must be restarted. Idling all processors for
kd mode is unavoidable as communication with the host must be
synchronized.
I don’t have any firm figures for how much overhead this synchronization
costs. I would guess that it’s less than a millisecond, so I wouldn’t
think it would explain things being so slow, but I guess it’s possible.
________________________________
From: xxxxx@lists.osr.com on behalf of Konstantin Manurin
Sent: Tue 7/25/2006 4:22 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Low speed of debug output while debugging over IEEE
1394
Philip,
Thank you very much for your quick and quite exact advice. That’s indeed
the case! I tested my target machine with /onecpu switch in the boot.ini
file and debug output strings were appearing on my host machine several
times (exactly several) faster than on the same target machine with MP
configuration. Maybe this issue of low debug output speed on MP systems
relates to extra synchronization? What can Microsoft gurus say about
this?
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be
correlated with
MP vs. UP targets. So far, in the very limited number of
test systems
we’ve looked at here, all the MP systems are slow, and all
the UP systems
are fast.
Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is
some cause for it
to stop scrolling.
There may be something obvious that we are overlooking, but
that’s the
symptoms we’ve seen.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Konstantin
Manurin
om> mailto:xxxxx “Kernel
Debugging Interest List”
Sent by:
mailto:xxxxx
bounce-257250-683 cc
xxxxx@lists.osr.com
No Phone Info
Subject
Available [windbg] Low speed
of
debug output
while debugging over
IEEE 1394
07/24/2006 11:56
AM
Please respond to
“Kernel Debugging
Interest List”
.com> mailto:xxxxx
Hi guys,
At last I resolved a problem with IEEE 1394 controllers and
cables. For
that I had to buy a new IEEE 1394 controller with at least
one 4-pin
connector on it because I couldn’t simply connect two IEEE
1394 controllers
(I tried some different controllers) via 6-to-6 pins cable.
Also I tested
several different cables but none of them allowed to even
establish a
network connection.
But now I have another problem. The thing is that speed of
debug output is
quite low, just as I would use debugging via COM ports.
Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of
course, response
time of WinDBG became a little bit better, but the debug
output speed makes
me really sad… Maybe there’s some hidden options for IEEE
1394 debug
connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
—
You are currently subscribed to windbg as:
xxxxx@seagate.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.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
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Drew,
Thanks for the information. Am I understanding correctly that DbgPrint
(along with every other part of the kernel debugger) uses the
synchronization described below? In other words, the kernel debugger sync
is one giant system-wide lock?
No criticism, just asking if I understood you correctly or not.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Drew Bliss”
Sent by: xxxxx@lists.osr.com
No Phone Info Available
07/26/2006 11:49 AM
Please respond to
“Kernel Debugging Interest List”
To
“Kernel Debugging Interest List”
cc
Subject
RE: [windbg] Low speed of debug output while debugging over IEEE 1394
Processors are stopped so that debugging can be done across all
processors. For example, switching processors when broken-in requires
that all processors are idle and ready to become the primary debugging
processor. There’s also global data that needs synchronization
protection.
You could certainly imagine more complicated locking schemes, such as
using different kinds of locks depending on the kind of communication or
even more complicated interlocks, but no such kernel changes are planned
due to the risk of subtle bugs.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, July 26, 2006 9:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Low speed of debug output while debugging over
IEEE 1394
Drew,
Why would they all need to be paused? Why not just use a highest-level
spinlock, such as the one in the InterlockedList routines discussed last
week? I’m sure I’m missing something, but it seems like DbgPrint() is
an ideal place to use an in-stack queued spinlock, and you don’t need to
shoot down the other CPUs for that…
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Drew Bliss”
osoft.com>
To
Sent by: “Kernel Debugging Interest List”
bounce-257370-683
xxxxx@lists.osr.com
cc
No Phone Info
Available
Subject
RE: [windbg] Low speed of debug
output while debugging over IEEE
07/25/2006 10:59 1394
AM
Please respond to
“Kernel Debugging
Interest List”
.com>
There is significantly more synchronization overhead for kd mode on MP
systems because all processors must be paused. This results in the
initiating processor sending IPIs to all other processors and everything
waiting until all processors have been idled. On resumption of
execution all processors must be restarted. Idling all processors for
kd mode is unavoidable as communication with the host must be
synchronized.
I don’t have any firm figures for how much overhead this synchronization
costs. I would guess that it’s less than a millisecond, so I wouldn’t
think it would explain things being so slow, but I guess it’s possible.
________________________________
From: xxxxx@lists.osr.com on behalf of Konstantin Manurin
Sent: Tue 7/25/2006 4:22 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Low speed of debug output while debugging over IEEE
1394
Philip,
Thank you very much for your quick and quite exact advice. That’s indeed
the case! I tested my target machine with /onecpu switch in the boot.ini
file and debug output strings were appearing on my host machine several
times (exactly several) faster than on the same target machine with MP
configuration. Maybe this issue of low debug output speed on MP systems
relates to extra synchronization? What can Microsoft gurus say about
this?
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be
correlated with
MP vs. UP targets. So far, in the very limited number of
test systems
we’ve looked at here, all the MP systems are slow, and all
the UP systems
are fast.
Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is
some cause for it
to stop scrolling.
There may be something obvious that we are overlooking, but
that’s the
symptoms we’ve seen.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Konstantin
Manurin
om> mailto:xxxxx “Kernel
Debugging Interest List”
Sent by:
mailto:xxxxx
bounce-257250-683 cc
xxxxx@lists.osr.com
No Phone Info
Subject
Available [windbg] Low speed
of
debug output
while debugging over
IEEE 1394
07/24/2006 11:56
AM
Please respond to
“Kernel Debugging
Interest List”
.com> mailto:xxxxx
Hi guys,
At last I resolved a problem with IEEE 1394 controllers and
cables. For
that I had to buy a new IEEE 1394 controller with at least
one 4-pin
connector on it because I couldn’t simply connect two IEEE
1394 controllers
(I tried some different controllers) via 6-to-6 pins cable.
Also I tested
several different cables but none of them allowed to even
establish a
network connection.
But now I have another problem. The thing is that speed of
debug output is
quite low, just as I would use debugging via COM ports.
Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of
course, response
time of WinDBG became a little bit better, but the debug
output speed makes
me really sad… Maybe there’s some hidden options for IEEE
1394 debug
connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
—
You are currently subscribed to windbg as:
xxxxx@seagate.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.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
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Correct, any communication with the kernel debugger requires entering kd
mode. kd mode always goes to HIGH_LEVEL IRQL, syncs processors,
disables interrupts, etc.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Wednesday, July 26, 2006 11:43 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Low speed of debug output while debugging over
IEEE 1394
Drew,
Thanks for the information. Am I understanding correctly that DbgPrint
(along with every other part of the kernel debugger) uses the
synchronization described below? In other words, the kernel debugger
sync is one giant system-wide lock?
No criticism, just asking if I understood you correctly or not.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Drew Bliss”
Sent by: xxxxx@lists.osr.com
No Phone Info Available
07/26/2006 11:49 AM
Please respond to
“Kernel Debugging Interest List”
To
“Kernel Debugging Interest List”
cc
Subject
RE: [windbg] Low speed of debug output while debugging over IEEE 1394
Processors are stopped so that debugging can be done across all
processors. For example, switching processors when broken-in requires
that all processors are idle and ready to become the primary debugging
processor. There’s also global data that needs synchronization
protection.
You could certainly imagine more complicated locking schemes, such as
using different kinds of locks depending on the kind of communication or
even more complicated interlocks, but no such kernel changes are planned
due to the risk of subtle bugs.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, July 26, 2006 9:35 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Low speed of debug output while debugging over
IEEE 1394
Drew,
Why would they all need to be paused? Why not just use a highest-level
spinlock, such as the one in the InterlockedList routines discussed last
week? I’m sure I’m missing something, but it seems like DbgPrint() is
an ideal place to use an in-stack queued spinlock, and you don’t need to
shoot down the other CPUs for that…
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
“Drew Bliss”
osoft.com>
To
Sent by: “Kernel Debugging Interest List”
bounce-257370-683
xxxxx@lists.osr.com
cc
No Phone Info
Available
Subject
RE: [windbg] Low speed of debug
output while debugging over IEEE
07/25/2006 10:59 1394
AM
Please respond to
“Kernel Debugging
Interest List”
.com>
There is significantly more synchronization overhead for kd mode on MP
systems because all processors must be paused. This results in the
initiating processor sending IPIs to all other processors and everything
waiting until all processors have been idled. On resumption of
execution all processors must be restarted. Idling all processors for
kd mode is unavoidable as communication with the host must be
synchronized.
I don’t have any firm figures for how much overhead this synchronization
costs. I would guess that it’s less than a millisecond, so I wouldn’t
think it would explain things being so slow, but I guess it’s possible.
________________________________
From: xxxxx@lists.osr.com on behalf of Konstantin Manurin
Sent: Tue 7/25/2006 4:22 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Low speed of debug output while debugging over IEEE
1394
Philip,
Thank you very much for your quick and quite exact advice. That’s indeed
the case! I tested my target machine with /onecpu switch in the boot.ini
file and debug output strings were appearing on my host machine several
times (exactly several) faster than on the same target machine with MP
configuration. Maybe this issue of low debug output speed on MP systems
relates to extra synchronization? What can Microsoft gurus say about
this?
Konstantin Manurin
Lately we’ve noticed that the slow 1394 speed seems to be
correlated with
MP vs. UP targets. So far, in the very limited number of
test systems
we’ve looked at here, all the MP systems are slow, and all
the UP systems
are fast.
Slow = you can see each line of debug spew appear.
Fast = same spew scrolls too fast to see until there is
some cause for it
to stop scrolling.
There may be something obvious that we are overlooking, but
that’s the
symptoms we’ve seen.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Konstantin
Manurin
om> mailto:xxxxx “Kernel
Debugging Interest List”
Sent by:
mailto:xxxxx
bounce-257250-683 cc
xxxxx@lists.osr.com
No Phone Info
Subject
Available [windbg] Low speed
of
debug output
while debugging over
IEEE 1394
07/24/2006 11:56
AM
Please respond to
“Kernel Debugging
Interest List”
.com> mailto:xxxxx
Hi guys,
At last I resolved a problem with IEEE 1394 controllers and
cables. For
that I had to buy a new IEEE 1394 controller with at least
one 4-pin
connector on it because I couldn’t simply connect two IEEE
1394 controllers
(I tried some different controllers) via 6-to-6 pins cable.
Also I tested
several different cables but none of them allowed to even
establish a
network connection.
But now I have another problem. The thing is that speed of
debug output is
quite low, just as I would use debugging via COM ports.
Earlier I thought
that the debugging over IEEE 1394 would be much faster. Of
course, response
time of WinDBG became a little bit better, but the debug
output speed makes
me really sad… Maybe there’s some hidden options for IEEE
1394 debug
connections? Or perhaps I’m wrong?
Any suggestions will be highly appreciated.
Best regards,
Konstantin Manurin
—
You are currently subscribed to windbg as:
xxxxx@seagate.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.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
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.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
— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>