Faster baud rates for Windbg serial...

WINDBG
1

I’m currently in the process of doing some kernel debugging, and I find
myself quite irritated at the very small pipe that the serial debugger
has to go through. I’m using some fairly capable machines as my targets
(hp dl3XX series servers) and it looks like the serial ports on them are
capable of higher speeds than the 115200 that the /baudrate parameter
seems limited to (hardware doc is unclear; they are stable at 115200).
On my debugger side, I use a 4-port USB-to-serial converter (a nice unit
made by keyspan), which is capable (it claims) of nearly a megabit
(921600) through the port. I can easily debug 8 machines through two of
these units on a single debug machine (which I need to do at times).

I’d love to use these higher speeds, if they were actually capable of
being used. It seems that WinDBG (or, more likely, Windows itself)
hasn’t quite kept up with the speeds available in the hardware. Are
there any plans to change this in future, or is the expected course to
go with 1394/USB?

(If it’s 1394/USB, MSFT should be evangelizing the blade hardware
vendors to add a “debug” option to their hardware offerings for the
blades; most of the blades out there don’t have dedicated serial ports
or any place to install 1394 or USB cards. This makes them a real pain
to debug drivers on, which is also necessary sometimes.)

Or maybe I’m just whining…

…dave

2

It’s 1394. I think the problem with higher bitrates on “standard” serial
ports is that there is no way to express the higher bitrates in the 16550
register set. You can get higher-speed serial ports, but they all need
their own driver. Since the kernel debugging support does not use a driver
(the support is built into ntoskrnl.exe itself), it cannot use a third-party
driver to drive a faster port.

Can you debug your driver on a different server, which has
1394/PCI/whatever? Then, once you’ve fixed the problem, debug on your blade
servers. Also, you can configure the blade servers to write full dump files
when they crash. Then, when they come back up, copy the dump files to your
debug machine and load them with “windbg -z foo.dmp”.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dave Beaver
Sent: Wednesday, March 15, 2006 2:27 PM
To: Kernel Debugging Interest List
Subject: [windbg] Faster baud rates for Windbg serial…

I’m currently in the process of doing some kernel debugging, and I find
myself quite irritated at the very small pipe that the serial debugger has
to go through. I’m using some fairly capable machines as my targets (hp
dl3XX series servers) and it looks like the serial ports on them are capable
of higher speeds than the 115200 that the /baudrate parameter seems limited
to (hardware doc is unclear; they are stable at 115200).
On my debugger side, I use a 4-port USB-to-serial converter (a nice unit
made by keyspan), which is capable (it claims) of nearly a megabit
(921600) through the port. I can easily debug 8 machines through two of
these units on a single debug machine (which I need to do at times).

I’d love to use these higher speeds, if they were actually capable of being
used. It seems that WinDBG (or, more likely, Windows itself) hasn’t quite
kept up with the speeds available in the hardware. Are there any plans to
change this in future, or is the expected course to go with 1394/USB?

(If it’s 1394/USB, MSFT should be evangelizing the blade hardware vendors to
add a “debug” option to their hardware offerings for the blades; most of the
blades out there don’t have dedicated serial ports or any place to install
1394 or USB cards. This makes them a real pain to debug drivers on, which is
also necessary sometimes.)

Or maybe I’m just whining…

…dave

You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

>Since the kernel debugging support does not use a driver

(the support is built into ntoskrnl.exe itself), it cannot
use a third-party driver to drive a faster port.

Well, that’s the rub, isn’t it? MSFT can tout the adoption of faster
“standard” usarts (what makes it standard is that everyone uses it) that
the built-in support can use at higher baudrates. But it’s currently a
chicken and egg problem, and without advocacy of faster rates from MSFT
(through the Windows PC design channels and WinHEC) this isn’t likely to
happen. Vendors need a good reason to increase the COGs, and there
currently isn’t one other than a tiny-whiney bunch of driver writers.
:wink:

I’ve been using WinDBG (and it’s predecessors, in one form or another)
over serial lines as long as there has been kernel debgugging for
Windows (literally), and this has always been a concern - it’s just like
a network, there’s no such thing as too fast.

As far as debugging on a different server, we’ve thought of and tried
that, of course. We have multiple drivers all the way up the stack from
the HBA to and through our filesystem. There are some edge case problems
that are specific to the hardware and which do not recur on other
machines. They may be HAL-related, who knows - some blade architectures
share devices across the chassis, so have some non-standard bus
architectures. The dump files are sometimes useful, but sometimes these
things show up as a transient condition that isn’t easily catchable with
a dump.

It’s probably time for me to get 1394 working on the machines I have
that are capable of supporting it (meaning they have more than one
slot). Oh joy, more time to spend fiddling around so I can get to the
work part.

Thanks …dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Wednesday, March 15, 2006 11:53 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Faster baud rates for Windbg serial…

It’s 1394. I think the problem with higher bitrates on “standard”
serial ports is that there is no way to express the higher bitrates in
the 16550 register set. You can get higher-speed serial ports, but they
all need their own driver. Since the kernel debugging support does not
use a driver (the support is built into ntoskrnl.exe itself), it cannot
use a third-party driver to drive a faster port.

Can you debug your driver on a different server, which has
1394/PCI/whatever? Then, once you’ve fixed the problem, debug on your
blade servers. Also, you can configure the blade servers to write full
dump files when they crash. Then, when they come back up, copy the dump
files to your debug machine and load them with “windbg -z foo.dmp”.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dave Beaver
Sent: Wednesday, March 15, 2006 2:27 PM
To: Kernel Debugging Interest List
Subject: [windbg] Faster baud rates for Windbg serial…
<>

—
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@polyserve.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

4

One more thing – Some system BIOSes support configuring serial ports to lie
about their bitrate, i.e. always run at 4x the value seen at the register
interface. These are rare, but if you can get one, you can use the stock KD
support and get 4x115200 bps (or whatever). I don’t know of any systems
off-hand that support this – it’s been a while since I’ve been stuck in
that same situation.

Still, the best path is probably finding a 1394 interface. Or USB – I’ve
not used USB for kernel debugging, since 1394 works so well. However, if
you go the 1394 route, make sure the 1394 chipset is one of the “known good”
implementations, such as the TI. OSR’s online site carries these PCI boards
at reasonable cost.

I realize this may be a pain in some situations, but I would much rather MS
kernel engineering effort be spent elsewhere than deal with some random UART
register sets, and only for KD.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dave Beaver
Sent: Wednesday, March 15, 2006 4:19 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Faster baud rates for Windbg serial…

Since the kernel debugging support does not use a driver (the support
is built into ntoskrnl.exe itself), it cannot use a third-party driver
to drive a faster port.

Well, that’s the rub, isn’t it? MSFT can tout the adoption of faster
“standard” usarts (what makes it standard is that everyone uses it) that the
built-in support can use at higher baudrates. But it’s currently a chicken
and egg problem, and without advocacy of faster rates from MSFT (through the
Windows PC design channels and WinHEC) this isn’t likely to happen. Vendors
need a good reason to increase the COGs, and there currently isn’t one other
than a tiny-whiney bunch of driver writers.
:wink:

I’ve been using WinDBG (and it’s predecessors, in one form or another) over
serial lines as long as there has been kernel debgugging for Windows
(literally), and this has always been a concern - it’s just like a network,
there’s no such thing as too fast.

As far as debugging on a different server, we’ve thought of and tried that,
of course. We have multiple drivers all the way up the stack from the HBA to
and through our filesystem. There are some edge case problems that are
specific to the hardware and which do not recur on other machines. They may
be HAL-related, who knows - some blade architectures share devices across
the chassis, so have some non-standard bus architectures. The dump files are
sometimes useful, but sometimes these things show up as a transient
condition that isn’t easily catchable with a dump.

It’s probably time for me to get 1394 working on the machines I have that
are capable of supporting it (meaning they have more than one slot). Oh joy,
more time to spend fiddling around so I can get to the work part.

Thanks …dave

5

Dave,

16550A UARTs reportedly can operate at speeds upto 1.5Mbps if one could
control the clock speed divisor (which is set at 16). Apparently it is
that way for PC XT (sheesh !!) compatibility. If one had control over
the divisor, I would think one could have such compatibility or higher
speeds if one needs. But I don’t know why this is not done.

Also I am not clear about how serial ports are supporting the 128kbps
setting and why windbg has issues with it. Debugging at 128kbps either
didn’t work or had intermittent failures, IIRC.

Satya

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dave Beaver
Sent: Wednesday, March 15, 2006 2:27 PM
To: Kernel Debugging Interest List
Subject: [windbg] Faster baud rates for Windbg serial…

I’m currently in the process of doing some kernel debugging, and I find
myself quite irritated at the very small pipe that the serial debugger
has
to go through. I’m using some fairly capable machines as my targets (hp
dl3XX series servers) and it looks like the serial ports on them are
capable
of higher speeds than the 115200 that the /baudrate parameter seems
limited
to (hardware doc is unclear; they are stable at 115200).
On my debugger side, I use a 4-port USB-to-serial converter (a nice unit
made by keyspan), which is capable (it claims) of nearly a megabit
(921600) through the port. I can easily debug 8 machines through two of
these units on a single debug machine (which I need to do at times).

I’d love to use these higher speeds, if they were actually capable of
being
used. It seems that WinDBG (or, more likely, Windows itself) hasn’t
quite
kept up with the speeds available in the hardware. Are there any plans
to
change this in future, or is the expected course to go with 1394/USB?

(If it’s 1394/USB, MSFT should be evangelizing the blade hardware
vendors to
add a “debug” option to their hardware offerings for the blades; most of
the
blades out there don’t have dedicated serial ports or any place to
install
1394 or USB cards. This makes them a real pain to debug drivers on,
which is
also necessary sometimes.)

Or maybe I’m just whining…

…dave

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@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com