This is a recoverable protocol. In the presence of errors, the throughput
would drop. So that’s why a lower speed will (net) result in higher
throughput.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Leahy, Barbara C [mailto:barbara.leahy@hp.com]
Sent: Monday, July 28, 2003 8:45 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into debugger
Yes, let me clarify my request.
What I’d like info on is why would a slower baud rate work
better than a faster one or would it. I know both machines must match
the baud rate and how to set the baud rate up. When I read the email
about baud rates, I got the impression that a slower baud rate may
worker better on some machines. Is this true? What I wanted to know is
if some machines will work at higher baud rates, but handle slower baud
rates better. Is there an ideal baud rate that works best with certain
machines? I want to know what the test guys have found works best.
Guess I’ll have to experiment on my own.
From my experience after updating my debugger today, what version of the
debugger I’m using makes a difference. I better keep the versions around
that I like.
Thanks, Barb
-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Friday, July 25, 2003 10:09 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger
On host, you set the serial line baudrate. When you selected Kernel
Debug from File menu in Com tab.
On target, you set the baudrate in your boot.ini using /baudrate=xxxx
The baudrate specified at the host and target should be the same. Look
windbg documentation for valid baudrate values…
-Srin.
-----Original Message-----
From: Leahy, Barbara C [mailto:barbara.leahy@hp.com]
Sent: Friday, July 25, 2003 7:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debuggerPlease expand more on the suggestion of using a slower baud rate on
the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in
hopes
it will help.I’ve found different results depending on the machine model of
the
target. I use the same the machine, a 2GHZ, as the debugger machine.
The debugee/target machine is either a 450 MHZ or a 1GHZ.
On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I
send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If
I
don’t do this and just try issuing more commands from the windbg
command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not
sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.So, if you are seeing your machine hung in the debugger, you may
want
to see if that same behavior happens on another machine of different
characteristics. That gives you another piece of
information
in the problem solving.Barb
-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, July 24, 2003 2:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debuggerI could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached
to
(e.g. usb)?It’s possible that the driver verifier might catch a failure before it
takes out the system (assuming that your driver is taking out the
system).Also using checked builds of the kernel / corresponding stacks may
also
provide additional hints of what’s going wrong. Likewise testing on a
newer o/s release (assuming that you’re testing on an older o/s
release
like W2K) might also expose the problem.Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling
the
1394 port on the target system.–Sandy
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debuggerHi,
I’m having trouble using windbg (and even just kd) to debug a driver
that I’ve written.If I don’t have windbg or kd running on my host, I can open a handle
to
my driver, and it can send bulk usb read requests down the usb stack
and
complete them without problems.However, if I have windbg or kd running and have managed to break into
the debugger and load symbols etc (but haven’t set any breakpoints),
then I can open a handle to my driver, but as soon as the completion
routine runs for a bulk usb read, the target freezes and windbg (and
kd)
fails to break into the debugger. I know it’s stuck in the completion
routine, because of the debug output statements I see. My only
recourse
at that point is to physically reset the target, and I don’t get to
see
the information I’m interested in.I’ve gotten about as far as I can debugging this driver using DbgPrint
statements and would like to actually use windbg (or even kd).
Any suggestions as to how I can get this working would be greatly
appreciated.Thanks,
Linda
You are currently subscribed to windbg as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@nai.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com