Download Kernel Debugging Guide

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Transcript
Windows Server 2008 SP2 and Windows
Server 2008 R2 SP1 on HP Integrity Servers
Kernel Debugging Guide
HP Part Number: T8704-96010
Published: May 2011
Legal Notices
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP
shall not be liable for technical or editorial errors or omissions contained herein.
Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.
Intel and Itanium are trademarks of Intel Corporation in the U.S. and other countries.
Java is a US trademark of Sun Microsystems, Inc.
UNIX is a registered trademark of The Open Group.
Table of Contents
About This Document.........................................................................................................7
Intended Audience.................................................................................................................................7
New and Changed Information in This Edition.....................................................................................7
Document Organization.........................................................................................................................7
Typographic Conventions......................................................................................................................7
Related Information................................................................................................................................8
Publishing History..................................................................................................................................8
HP Encourages Your Comments............................................................................................................9
1 Debugging the kernel locally......................................................................................11
Overview...............................................................................................................................................11
Setting up the host machine..................................................................................................................12
Install Debugging Tools for Windows.............................................................................................13
Building a converter for your cable......................................................................................................14
Build a 5x2-to-DB9M converter (rx1620).........................................................................................14
Build a RJ45-to-DB9F converter (rx5670, rx7620, rx8620, and Superdome/sx1000)........................14
Setting up and connecting to the target machine.................................................................................16
Change the boot configuration (applies to all servers)...................................................................16
Windows Server 2003 Systems Only ⇒ Option 1: Using Bootcfg (recommended)...................17
Windows Server 2003 Systems Only ⇒ Option 2: Using Nvrboot............................................19
Windows Server 2008 Systems Only ⇒ Using BCDEdit...........................................................20
rx1620 server....................................................................................................................................21
rx2600 and rx2620 servers................................................................................................................21
rx2660 servers..................................................................................................................................21
rx3600 and rx6600 servers................................................................................................................22
rx4640 server....................................................................................................................................22
rx5670 server....................................................................................................................................23
rx7620, rx8620, and Superdome/sx1000 servers..............................................................................24
Locate the debug port................................................................................................................24
Option 1: Identifying the core cell using an EFI command (recommended).......................24
Option 2: Identifying the core cell using an nPartition command.......................................25
Copy the KD utility to the EFI system partition (applies to rx7620 and rx8620 servers
only)............................................................................................................................................25
Enable the debugging port (applies to rx7620 and rx8620 servers only)...................................25
Connect to the debug port..........................................................................................................26
BL860c/BL870c server blades and rx2800 i2 server.........................................................................27
BL860c i2, BL870c i2, and BL890c i2 server blades..........................................................................28
2 Debugging the kernel remotely..................................................................................31
Overview...............................................................................................................................................31
Setting up the host machine..................................................................................................................31
Install Debugging Tools for Windows.............................................................................................32
Setting up and connecting to the target machine.................................................................................33
Change the boot configuration........................................................................................................33
Windows Server 2003 Systems Only ⇒ Option 1: Using Bootcfg (recommended)...................33
Windows Server 2003 Systems Only ⇒ Option 2: Using Nvrboot............................................36
Windows Server 2008 Systems Only ⇒ Using BCDEdit...........................................................37
Enable IPMI LAN access and the debugging option......................................................................38
Connect with the target machine and initiate debugging...............................................................38
Table of Contents
3
3 Debugging HP Virtual Machines guests....................................................................39
HPVM Windows guest debug process.................................................................................................39
4
Table of Contents
List of Figures
1-1
1-2
1-3
1-4
1-5
1-6
1-7
1-8
1-9
1-10
1-11
1-12
1-13
rx1620 debug port (male pins on system board)...........................................................................14
Required plug ends and internal wiring.......................................................................................15
rx1620 debugging port..................................................................................................................21
rx2600 and rx2620 debugging port................................................................................................21
rx2660 debugging port..................................................................................................................22
rx3600 and rx6600 debugging port................................................................................................22
rx4640 debugging port..................................................................................................................23
Location of three jumpers on rx4640 motherboard.......................................................................23
rx5670 debugging port..................................................................................................................24
Debugging port on the rx8620.......................................................................................................26
Debugging port on Superdome/sx1000.........................................................................................27
BL860c/BL870c debugging port, front panel.................................................................................28
rx2800 i2 debugging port, back panel...........................................................................................28
5
List of Tables
1-1
1-2
1-3
1-4
1-5
6
Kernel debugging setup options...................................................................................................11
DB9 male pin-out to 5x2 female....................................................................................................14
Computer pin-outs or HP Integrity rx5670 servers.......................................................................15
Computer pin-outs for HP Integrity rx7620 and rx8620 servers...................................................15
Computer pin-outs for HP Integrity Superdome/sx1000 servers.................................................15
List of Tables
About This Document
This document describes the process for debugging the operating system kernel on HP Integrity
servers running Microsoft Windows® Server 2008 SP2 and Windows® Server 2008 R2 SP1.
The document printing date and part number indicate the document’s current edition. The
printing date changes when a new edition is printed. Minor changes may be made at reprint
without changing the printing date. The document part number changes when extensive changes
are made.
Document updates may be issued between editions to correct errors or document product changes.
To ensure that you receive the updated or new editions, you should subscribe to the appropriate
product support service. See your HP sales representative for details.
For the latest version of this document, see the HP Technical Documentation website:
http://www.hp.com/go/windows-on-integrity-docs
Intended Audience
This document is intended for system administrators and HP support personnel responsible for
installing, configuring, and managing HP Integrity servers. This document is not a tutorial.
New and Changed Information in This Edition
This document includes the following changes since its last release:
• Publishing History: updated table content for 7.1 release; added rx2800 i2 support
• Overview: added rx2800 i2 server to first row in table
• BL860c and BL870c Server Blades: changed this section to include rx2800 i2 server; added
photo
Document Organization
This document is organized as follows:
“Debugging the kernel locally”
(page 11)
Describes how to debug the OS kernel locally. In a local debugging environment,
you are physically located near the server you want to debug. You use a host
machine, typically a laptop, that has the Windows debugging software installed
on it. You connect the host machine to the server with a cable and begin the
debugging process.
“Debugging the kernel remotely” Describes how to debug the OS kernel remotely. In a remote debugging
(page 31)
environment, you are not physically located near the server you want to debug.
You use a host machine, typically a laptop, that has the Windows debugging
software installed on it. You connect the host machine to the server across a LAN
and begin the debugging process.
“Debugging HP Virtual
Machines guests” (page 39)
Describes how to debug the virtual machine guests.
Typographic Conventions
This document uses the following typographical conventions:
WARNING
A warning calls attention to important information that if not understood
or followed will result in personal injury or nonrecoverable system
problems.
CAUTION
A caution calls attention to important information that if not understood
or followed will result in data loss, data corruption, or damage to
hardware or software.
Intended Audience
7
IMPORTANT
This alert provides essential information to explain a concept or to
complete a task
NOTE
A note contains additional information to emphasize or supplement
important points of the main text.
KeyCap
The name of a keyboard key or graphical interface item (such as buttons,
tabs, and menu items). Note that Return and Enter both refer to the
same key.
Computer output
Text displayed by the computer.
User input
Commands and other text that you type.
Command
A command name or qualified command phrase.
Ctrl+x
A key sequence. A sequence such as Ctrl+x indicates that you must hold
down the key labeled Ctrl while you press another key or mouse button.
Related Information
You can find more information about HP Integrity servers, server management, and software
in the following locations:
•
For an overview of Windows on HP Integrity servers:
http://h20341.www2.hp.com/integrity/w1/en/os/windows-on-integrity-overview.html
•
For other documents supporting Windows Server 2008 SP2 and Windows Server 2008 R2
SP1 on HP Integrity Servers:
— to locate documents by operating system:
http://www.hp.com/go/windows-on-integrity-docs
— to locate documents by server model number:
http://www.hp.com/go/integrity_servers-docs
•
For technical support resources (drivers, patches, upgrades, migration issues, to sign up for
alerts, and so on):
http://hp.com/support/itaniumservers
Publishing History
The document part number and publication date indicate the document’s current edition. The
publication date will change when a new edition is printed. Minor changes may be made at
reprint without changing the publication date. The document part number will change when
extensive changes are made. Document updates may be issued between editions to correct errors
or document product changes. To ensure that you receive the updated or new editions, you
8
should subscribe to the appropriate product support service. See your HP sales representative
for details.
Manufacturing Part
Number
Supported Operating
Systems
Supported Smart
Setup Version
Supported Products
(Servers)
Publication Date
T8704–96000
Microsoft Windows
Server 2008 with
Service Pack 2 (SP2)
for Itanium-based
Systems
Version 7.0
BL860c
August, 2010
BL870c
BL860c i2
BL870c i2
Microsoft Windows
Server 2008 R2
Itanium Edition
BL890c i2
rx2660
rx3600
rx6600
rx7640
rx8640
Superdome sx2000
T8704–96010
Microsoft Windows
Server 2008 with
Service Pack 2 (SP2)
for Itanium-based
Systems
Microsoft Windows
Server 2008 R2 with
Service Pack 1 (SP1)
Itanium Edition
Version 7.1
BL860c
May, 2011
BL870c
BL860c i2
BL870c i2
BL890c i2
rx2800 i2
rx2660
rx3600
rx6600
rx7640
rx8640
Superdome sx2000
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to providing
documentation that meets your needs. Send any errors found, suggestions for improvement, or
compliments to:
[email protected]
Please include the document title, manufacturing part number, and any comment, error found,
or suggestion for improvement you have concerning this document.
HP Encourages Your Comments
9
10
1 Debugging the kernel locally
If you have programmed on the Windows operating system for any length of time, you are
probably familiar with user-mode debuggers and aware of kernel-mode debuggers. User-mode
debuggers help developers to debug applications. Kernel-mode debuggers are used mostly by
driver writers to debug device drivers and by support professionals to analyze system crashes.
This chapter describes how to locally debug the operating system kernel on HP Integrity servers.
In a local debugging environment, you are physically located near the server you want to debug.
You use a host machine, typically a laptop, that has the Windows debugging software installed
on it. You connect the host machine to the server with a cable (this sometimes requires the use
of a custom-made converter plug), and begin the debugging process.
NOTE: You can use the local debugging procedures described in this chapter on all HP Integrity
servers, except the following:
•
•
•
HP Integrity rx7640 servers
HP Integrity rx8640 servers
HP Integrity Superdome servers with the sx2000 chipset
You debug these servers remotely, over a LAN, using the methods described in the next chapter.
Overview
A typical local kernel debugging environment for Windows systems consists of a host machine,
which runs the debugging software; a connecting cable (and sometimes a custom-made converter
plug); and an HP Integrity server target machine. The host is usually a laptop with Microsoft
Debugging Tools for Windows (x86) software installed, and the cable is either a null modem
serial or CAT-5 cable. The target is always an HP Integrity server for the purposes of this guide.
Use the following table to determine which setup is required, based on your target:
Table 1-1 Kernel debugging setup options
Host (+ Debugging software)
Cable (+ Converter)
Target
Overview
11
Table 1-1 Kernel debugging setup options (continued)
Laptop or workstation
+
Microsoft Debugging Tools for
Windows
Serial (RS232) null modem cable (DB9 Works with the following HP Integrity
female)
server models:
• BL860c
+
• BL870c
5x2-to-DB9M converter (for rx1620
• BL860c i2
only)
• BL870c i2
• BL890c i2
• rx2800 i2
• rx1620
• rx2600
• rx2620
• rx2660
• rx3600
• rx4640
• rx6600
Laptop or workstation
CAT-5 cable (RJ45)
+
+
Microsoft Debugging Tools for
Windows
RJ45-to-DB9F converter
Laptop or workstation
No cable required.
+
(These servers are debugged
remotely, over a LAN, as described
in the next chapter.)
Microsoft Debugging Tools for
Windows
Works with the following HP Integrity
server models:
• rx5670
• rx7620
• rx8620
• Superdome/sx1000
Works with the following HP Integrity
server models:
• rx7640
• rx8640
• Superdome/sx2000
The following sections provide instructions for setting up the host, building a cable converter if
necessary, setting up the target, and connecting the components with the cable. Setting up the
host involves installing the debugging tools. Setting up the target can involve locating and
enabling the kernel debug port and adding a boot configuration option to the operating system.
IMPORTANT: Using the Microsoft Debugging Tools for Windows software to debug kernel
problems is beyond the scope of this document. Debugging the kernel requires deep knowledge
of operating system internals and familiarity with the architecture of the HP Integrity servers.
This is best done by someone with expertise in both areas.
Setting up the host machine
The host is a machine that runs the debugging session. In a typical environment, the host is the
computer that is connected to the target (the machine being debugged) and that runs the debug
tools.
Microsoft provides the Debugging Tools for Windows software, which is a package of extensible
tools for debugging user-mode and kernel-model programs on the Windows family of operating
systems. The Debugging Tools for Windows package contains four debuggers: CDB, NTSD, KD,
and WinDbg.
•
•
12
Console Debugger (CDB) and NT Symbolic Debugger (NTSD) are console applications
that can debug user-mode programs. These two debuggers are nearly identical except in
the manner in which they are launched.
Kernel Debugger (KD) is a character-based console application that enables in-depth analysis
of kernel-mode activity on all operating systems based on Windows. You can use KD
(kd.exe) to debug kernel-mode programs and drivers or to monitor the behavior of the
Debugging the kernel locally
•
operating system itself. KD also supports multiprocessor debugging. Typically, the KD tool
runs on the host but not on the computer being debugged.
Windows Debugger (WinDbg) is a powerful debugging tool capable of both user-mode
and kernel-mode debugging. WinDbg (windbg.exe) provides full source-level debugging
for the Windows kernel, kernel-mode drivers, system services, and for user-mode applications
and drivers. WinDbg can view source code, variables, stack traces, and memory. It can also
set breakpoints.
Debugging Tools for Windows includes an online help file with detailed documentation about
each tool. See this help file for more information.
Install Debugging Tools for Windows
Versions of the Debugging Tools for Windows package are available for 32-bit x86, native Intel
Itanium, and native x64 platforms. Choose the package version based on the processor of the
host computer. Typically, you would select the Debugging Tools for Windows (x86) 32-bit
package.
x86 Host
If the host uses an x86 processor, always use the 32-bit package.
Itanium Host
If, like the target, the host is Itanium-based — an entry-level HP Integrity
server being used as a development platform, for example — then the
following rules apply:
• To analyze a dump file, use either the 32-bit package or the Itanium
package. It does not matter whether the dump file is a user-mode dump
file or a kernel-mode dump file.
• To perform live kernel-mode debugging, use either the 32-bit package
or the Itanium package. It does not matter whether the target is an
Itanium-based machine.
• To perform live user-mode debugging, always use the Itanium package.
It does not matter whether the target is a 64-bit application or a 32-bit
application.
You can install the Debugging Tools for Windows package from the Windows Driver Development
Kit (DDK), Platform Software Development Kit (SDK), or the Customer Support Diagnostics
CD. You can also download the latest release of the package from the Web. The package is
updated frequently. To ensure that you have the most up-to-date tools for the task, obtain the
package from the Web site:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
If you select Custom Install, you can control which features in this package are installed. The
Custom Install options are as follows:
•
•
•
•
The Debuggers feature is selected by default. If you leave this selected, installation includes
the debuggers WinDbg, KD, CDB, and NTSD; associated modules, such as DbgHelp; the
symbol server SymSrv; the source server SrcSrv; the dump file tool ADPlus; the remote
debugging tool DbgSrv; and several extension libraries.
The Tools feature and its Helpful Tools subfeature are selected by default. If you leave these
selected, installation includes the tools SymStore, SymChk, DbgRpc, Logger, LogViewer,
KDbgCtrl, DumpChk, GFlags.exe, TList.exe, Kill.exe, List.exe, Breakin.exe,
and UMDH, as well as the remote debugging tools Remote.exe, DbEngPrx, and KdSrv.
The Documentation feature and its Debugging Tools subfeature are selected by default. If
you leave these selected, installation includes the Debugging Tools for Windows
documentation (debugger.chm).
The SDK feature and its subfeatures are not selected by default. If you select these features,
installation includes the headers and libraries necessary to build debugger extensions, several
sample extensions and other samples, the “Debug Help Library” documentation
(dbghelp.chm), and the source server documentation (srcsrv.doc).
Setting up the host machine
13
After the installation completes, and after you complete the other required tasks, such as preparing
your cable and setting up the target machine, you can launch the Windows Debugger (WinDbg)
by selecting Start > All Programs > Debugging Tools for Windows > WinDbg.
Building a converter for your cable
Some HP Integrity servers do not have a DB9 serial port. To connect the host to these servers,
you must build or buy a converter plug to use to connect a cable to the debug port on the server.
The following sections provide pin-out details for the debug ports on each server, so you can
make the converter you need.
Build a 5x2-to-DB9M converter (rx1620)
On the rx1620 system board, the kernel debug port 5x2 male pins are wired as follows:
Figure 1-1 rx1620 debug port (male pins on system board)
You can sometimes find a 5x2-to-DB9M converter in electronics surplus stores because it was
often used on the motherboards of older computers. If you cannot locate one, you can build the
connector yourself using the information in the following table.
Table 1-2 DB9 male pin-out to 5x2 female
DB9 Male Pin
Signal Description
5x2 Female Connector
1
CD (carrier detect)
1
2
RX (receive data)
2
3
TX (transmit data)
3
4
DTR (data terminal ready)
4
5
GND (ground)
5
6
DSR (data set ready)
6
7
RTS (request to send)
7
8
CTS (clear to send)
8
9
RI (ring indicator)
9
—
—
10
Build a RJ45-to-DB9F converter (rx5670, rx7620, rx8620, and Superdome/sx1000)
The following picture shows the orientation of the individual wires inside the required plug
ends (RJ45 and DB9 Female).
14
Debugging the kernel locally
Figure 1-2 Required plug ends and internal wiring
Use these wiring details and one of the following pin-out tables to build the RJ45-to-DB9F
converter that applies to your server model number.
Table 1-3 Computer pin-outs or HP Integrity rx5670 servers
RJ45 Pin
Wire Color
DB9 Female Pin
1
Blue
1
2
Orange
3
3
Black
2
4
Red
4
5
Green
5
6
Yellow
6
7
Brown
7
8
Gray (White)
8
Table 1-4 Computer pin-outs for HP Integrity rx7620 and rx8620 servers
RJ45 Pin
Wire Color
DB9 Female Pin
1
Blue
4
2
Orange
8
3
Black
5
4
Red
3
5
Green
2
6
Yellow
NC
7
Brown
7
8
Gray (White)
6
Table 1-5 Computer pin-outs for HP Integrity Superdome/sx1000 servers
RJ45 Pin
Wire Color
DB9 Female Pin
1
Blue
7
2
Orange
5
3
Black
NC
Building a converter for your cable
15
Table 1-5 Computer pin-outs for HP Integrity Superdome/sx1000 servers (continued)
RJ45 Pin
Wire Color
DB9 Female Pin
4
Red
8
5
Green
3
6
Yellow
NC
7
Brown
2
8
Gray (White)
NC
Setting up and connecting to the target machine
To set up the server and initiate local debugging, complete the following steps:
1. Change the boot configuration (required for all servers).
2. Locate and enable the correct debug port (required for cell-based servers with multiple
operating system instances and BL860c/BL870c blade servers).
3. Connect the host machine to the server debugging port.
Because you must reboot for the boot configuration changes to take effect, change the boot options
first, locate and enable the debug port if necessary, and then connect the cable to the debug port
and proceed with debugging.
The procedures that follow are presented in the order they should be performed. Some sections
apply to all servers; some apply to certain models only, as indicated in the title. Follow only the
instructions in the sections that are marked with your server model number and in the sections
marked “applies to all servers.”
Change the boot configuration (applies to all servers)
To perform kernel-mode debugging, you must enable and configure certain features that are
established when the operating system loads. The settings for these features are included in the
boot options — values that determine how the boot loader loads and configures the operating
system and other bootable programs and devices. Windows Server 2003 and Windows Server
2008 use different mechanisms to store these boot options. Consequently, different procedures
and tools must be used to set or change them.
In systems running Windows Server 2003, you can edit the boot options in Extensible Firmware
Interface (EFI) nonvolatile RAM (NVRAM) in two ways, using different tools:
•
•
16
Bootcfg (bootcfg.exe) is a command-line tool that enables you to edit boot options while
the operating system is running. You can use Bootcfg to add, delete, and change the values
of all valid boot options. You can also use Bootcfg commands in a script or batch file to set
boot options or to reset them after you replace or upgrade an operating system.
Nvrboot (nvrboot.efi) is an EFI-based boot entry editor that you can run when the
operating system is shut down. Nvrboot edits boot entries and includes commands to export
backup copies of boot entries and to import backup copies of boot entries into NVRAM.
You can access Nvrboot from the EFI Shell in the msutil directory of the system partition
(fsN:/msutil/nvrboot.efi, where N is the number of the file system).
Debugging the kernel locally
In systems running Windows Server 2008, you must edit the boot options with a different tool:
•
BCDEdit (bcdedit.exe) is a command-line tool for adding, deleting, editing, and modifying
boot data in a boot configuration data (BCD) store. The usage information provided below
is a quick summary of some of the main features. For a complete description of all arguments
and parameters, refer to the Microsoft documentation found here:
http://technet.microsoft.com/en-us/library/cc709667(WS.10).aspx
Windows Server 2003 Systems Only ⇒ Option 1: Using Bootcfg (recommended)
To edit boot options using the Bootcfg tool, complete the following steps:
1.
At the command-line prompt, enter the following command:
C:\>bootcfg
The current boot configuration appears, as shown in the following example:
Boot Options
-----------Timeout: 20
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
CurrentBootEntryID: 1
Boot Entries
-----------Boot entry ID: 1
OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID: 2
OS Friendly Name: Internal Bootable DVD
Boot entry ID: 3
OS Friendly Name: EFI Shell [Built-in]
In this example, you can see that “Boot entry ID 1” is the default Windows boot option. It
has only the out-of-band management (EMS or SAC prompt) configured as an option (the
“redirect” option). On some systems, the NOVESA option is listed here, too.
You must add a couple of options to enable live debugging. Make a copy of the boot entry
and then add the options.
2.
Make a copy of the default boot entry by issuing the following command:
C:\>bootcfg /copy /d “Windows Server 2003, Enterprise with Debugging
Enabled” /id 1
The system indicates that it successfully copied boot entry “1.”
The new entry is copied to the bottom of the list and becomes the last entry. Because the
previous example contains only three boot entries, the new boot entry is assigned “ID 4”
(remember, this is only an example; if your system has more boot options, your ID number
will be higher).
3.
Issue the bootcfg command again to see the new boot entry ID 4:
C:\>bootcfg
The new boot configuration appears:
Setting up and connecting to the target machine
17
Boot Options
-----------Timeout: 20
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
CurrentBootEntryID: 1
Boot Entries
-----------Boot entry ID: 1
OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID: 2
OS Friendly Name: Internal Bootable DVD
Boot entry ID: 3
OS Friendly Name: EFI Shell [Built-in]
Boot entry ID: 4
OS Friendly Name: Windows Server 2003, Enterprise with Debugging Enabled
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry 4 is the same as boot entry 1 except for the description (or operating
system-friendly name).
4.
Add the Debug and Baud options to boot entry 4 by executing the following command:
C:\>bootcfg /debug on /baud 115200 /id 4
The system indicates that the operating system load options were changed for boot entry
ID 4.
In this example, the baud rate is configured at 115200. If your laptop does not support this
speed, try a different value, such as 38400. Remember to use the same value in the kernel
debugger where appropriate.
18
Debugging the kernel locally
5.
To confirm that the entries were added correctly, run the bootcfg command again:
C:\>bootcfg
The new boot configuration appears:
Boot Options
-----------Timeout: 20
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
CurrentBootEntryID: 1
Boot Entries
-----------Boot entry ID: 1
OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efiOsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID: 2
OS Friendly Name: Internal Bootable DVD
Boot entry ID: 3
OS Friendly Name: EFI Shell [Built-in]
Boot entry ID: 4
OS Friendly Name: Windows Server 2003, Enterprise with Debugging Enabled
OsLoadOptions: /redirect /debug /baudrate=115200
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID 4 now shows the debug and baud rate switches. As mentioned previously, a
COM port entry is not required for HP Integrity servers.
Windows Server 2003 Systems Only ⇒ Option 2: Using Nvrboot
To edit boot options using the Nvrboot tool, complete the following steps:
1.
From the EFI shell, navigate to the MSUTIL directory and execute the NVRBOOT.EFI
command, as shown here:
fs1:\> dir
Directory of: fs1:\
03/25/03 05:00a 841,216 SETUPLDR.EFI
06/25/03 11:14a <DIR> 1,024 EFI
06/25/03 11:14a <DIR> 1,024 MSUtil
2 File(s) 841,343 bytes
2 Dir(s)
fs1:\> cd msutil
fs1:\MSUtil> nvrboot
2.
Select M(Modify) to modify the operating system boot loader.
Setting up and connecting to the target machine
19
3.
At the Enter OS boot option to modify: prompt, select the first boot option by
entering: 1. The system displays the following:
1 LoadIdentifier = Windows Server 2003, Datacenter
2 OsLoadOptions = /REDIRECT /NOVESA
3 EfiOsLoaderFilePath = cf5f2ddc-b885-11d7-b831-000000000000 ::
\efi\microsoft\winnt50\ia64ldr.efi
4 OsLoaderFilePath = e605a034-b885-11d7-b831-000000000000 :: \windows
Enter VAR to modify: 2
4.
5.
At the Enter VAR to modify: prompt, select the second variable to modify
(OsLoadOptions) by entering: 2.
Reenter the OsLoadOptions variable, this time adding the /DEBUG and /BAUDRATE switches,
as follows:
OsLoadOptions=/REDIRECT /NOVESA /DEBUG /BAUDRATE=115200
NOTE: The /NOVESA switch is needed only on cell-based servers running Windows Server
2003 without SP1 and with a VGA card installed in the nPartition.
6.
Verify that the change was made by repeating step 1 through step 3. The system displays
the following:
1 LoadIdentifier = Windows Server 2003, Datacenter
2 OsLoadOptions = /REDIRECT /NOVESA /DEBUG /BAUDRATE=115200
3 EfiOsLoaderFilePath = cf5f2ddc-b885-11d7-b831-000000000000 ::
\efi\microsoft\winnt50\ia64ldr.efi
4 OsLoaderFilePath = e605a034-b885-11d7-b831-000000000000 :: \windows
7.
After verifying the changes to the OsLoadOptions variable, exit and boot the operating
system.
After debugging is complete, remove the /DEBUG and /BAUDRATE=115200 switches from the
boot configuration OsLoadOptions variable and reboot the operating system.
Windows Server 2008 Systems Only ⇒ Using BCDEdit
The values you assign with this tool depend on the type of connection you are trying to make
with the target system. At any time from the command line you can enter the following commands
to see the online help regarding tool usage:
bcdedit /?
or
bcdedit /dbgsettings /?
To enable debugging for a typical serial connection in Windows Server 2008, complete the
following steps:
1.
Make a copy of the default boot entry by issuing the following command:
C:\>bcdedit /copy {identifier_of_boot_entry_to_be_copied} /d
“original non-debug boot entry”
The system indicates that it successfully copied the boot entry with a new description.
2.
Set the connection type and baud rate for the debugger:
C:\>bcdedit /dbgsettings SERIAL BAUDRATE:115200
20
Debugging the kernel locally
3.
Enable the debugger for the desired boot entry:
C:\>bcdedit /debug
{identifier_of_boot_entry_targeted_for_kernel_debugging} ON
Once again, for a complete description this tool, refer to the Microsoft documentation found
here:
http://technet.microsoft.com/en-us/library/cc709667(WS.10).aspx
rx1620 server
Connect the cable between the laptop (host) and the rx1620 server (target) using the 5x2-to-DB9M
converter as shown in the following image.
Figure 1-3 rx1620 debugging port
When you face the front of the server, the first pin (#1) is located in the lower right corner of the
rectangle shown in the previous image. It is also indicated directly on the board with a small
white circle or a similar mark.
rx2600 and rx2620 servers
For rx2600 and rx2620, connect the serial port on the laptop or workstation to the DB9 port in
the back of the server using a standard DB9 female-terminated RS-232 null modem cable. The
following image shows the location of the DB9 port.
Figure 1-4 rx2600 and rx2620 debugging port
rx2660 servers
For rx2660 servers, connect the serial port on the laptop or workstation to the DB9 port marked
“Auxiliary”, located on the back of the server, using a standard DB9 female-terminated RS-232
null modem cable. The following image shows the location of the DB9 port.
Setting up and connecting to the target machine
21
Figure 1-5 rx2660 debugging port
rx3600 and rx6600 servers
For rx3600 and rx6600 servers, connect the serial port on the laptop or workstation to the serial
port on the far right side of the back of the server (when facing the back). The following image
shows the connection.
Figure 1-6 rx3600 and rx6600 debugging port
rx4640 server
The rx4640 server has 3 DB9 connectors on the rear I/O panel. The connector labeled “remote”
(the one closest to the VGA connector) is used as the kernel debug port, but it is not enabled by
default. The following image shows the location of this connector.
22
Debugging the kernel locally
Figure 1-7 rx4640 debugging port
To enable the debug port, you must open the server's I/O bay and short a jumper header as
follows (jumper not provided):
1.
2.
Power the system off and verify that it is disconnected from the main AC power supply.
Locate the set of three jumpers directly above the brown edge connector socket (the one
resembling an AGP slot) on the motherboard, as shown in the following image.
Figure 1-8 Location of three jumpers on rx4640 motherboard
3.
4.
Short the middle jumper header, which is the one labeled “console mux.”
Power the server on. You can now use the “remote” DB9 port as a debugging port with a
DB9 female-terminated RS-232 null modem cable.
rx5670 server
On the rx5670 server, connect the 4-pair CAT-5 cable to the RJ45 port shown in the following
image.
Setting up and connecting to the target machine
23
Figure 1-9 rx5670 debugging port
rx7620, rx8620, and Superdome/sx1000 servers
To set up the rx7620, rx8620, or Superdome/sx1000 for local debugging, complete the following
steps:
1. Locate the correct debugging port by identifying the core cell.
2. Copy the KD utility to the EFI system partition (rx7620 and rx8620 only).
3. Enable debug port (rx7620 and rx8620 only).
4. Connect to the debug port.
Locate the debug port
HP Integrity rx7620, rx8620, and Superdome servers are cell-based. They can be divided into
multiple node partitions (nPartitions), in which each nPartition has one or more cells. The
nPartitions are functionally isolated from each other so you can run a separate instance of the
operating system in each. You must connect the 4-pair CAT-5 cable to the RJ45 connector on the
core cell (or root cell) of the nPartition you want to debug. This means you must first identify
the core cell.
NOTE: The terms “core cell” and “root cell” mean the same thing. The Partition Manager and
the nPartition CLI tools generally use the term “core cell,” whereas the EFI tools use the term
“root cell.”
Use the following rules to identify the core cell:
•
•
•
If an nPartition has only one cell, it must be the core cell.
If the nPartition has more than one cell but only one I/O chassis, then the cell with the I/O
chassis is the core cell.
If the nPartition has more than one cell or more than one I/O chassis (or if you just do not
know), then use one of the following methods to determine the core cell.
Option 1: Identifying the core cell using an EFI command (recommended)
To identify the core cell from the EFI shell (while the operating system is shut down), execute
the following command:
fs1:\>rootcell
The system displays the following output:
Preferred Cab/
Root Cell Slot
Warnings
--------- ----- -------0
0/0
The current root cell is 0.
24
Debugging the kernel locally
In this example, the root cell is cell 0, physically the topmost cell in the server.
Option 2: Identifying the core cell using an nPartition command
To identify the nPartition’s core cell while the operating system is running:
• You must know the server IPMI password.
• You must know the IP address or host name of the server’s management processor.
• You have a workstation or laptop with the ParCLI tool installed.
• The laptop or workstation is on a network connected to the management processor.
Execute the nPartition parstatus command as follows:
C:\> parstatus -g ipmi_password -h MP_address
This command can take up to 2 minutes to complete. The output lists the number of nPartitions
in the system, the number of cells and I/O chassis, and the core cells, as shown here:
[Partition]
Par
Num Status
=== ============
0
Active
1
Active
# of
Cells
=====
2
2
# of I/O
Chassis Core cell Partition Name (first 30 chars)
======= ========== ==============================
2
cab0,cell0 RX8620-00 11.23
2
cab0,cell1 RX8620-01 Windows 2003
The output shows two nPartitions. For nPartition 0, the core cell is “cab 0, cell 0." For nPartition
1, the core cell is “cab 0, cell 1."
Copy the KD utility to the EFI system partition (applies to rx7620 and rx8620 servers only)
These HP Integrity servers have a kernel debugging port that is shared with a support debugging
port (used by HP field personnel). By default, this shared port operates as a support debugging
port. To enable the port for local kernel debugging, you must use an EFI-based utility called
KD.EFI.
To run KD.EFI, you must first copy the utility to the EFI system partition, shut down the operating
system, and then boot to the EFI Shell.
To access the EFI System Partition from Windows, you must identify it with a drive letter. Use
the mountvol command to mount the EFI system partition as shown here:
NOTE:
You must have administrative privileges to use the MOUNTVOL.EXE command.
mountvol e: /s
The /s option mounts the EFI System Partition so the operating system recognizes it as a normal
drive. Then, copy or drag-and-drop the KD.EFI file from the Smart Setup CD to the EFI system
partition.
Enable the debugging port (applies to rx7620 and rx8620 servers only)
To enable the debug port, complete the following steps:
Setting up and connecting to the target machine
25
1.
At the EFI Shell prompt, enter the following command:
EFI Shell> kd -on
Now the shared port on the core cell is enabled for kernel debugging. The state of the port
is consistent across reboots. However, removing power to the system reverts the debug port
back to its default state.
The system displays the following:
============================
KD Kernel Debug Port Enabler
============================
The KD port has been turned ON
Any changes to the KD port will remain persistent across reboots
and power down, as long as power is supplied to the server.
EFI Shell>
2.
When debugging operations are complete, enter the following at the EFI command line to
revert the debugging port back to its default state:
EFI Shell> kd -off
To display the current port state at any time, enter the kd command without any options.
Connect to the debug port
When you know which cell is the core cell, you can connect the 4-pair CAT-5 cable to the RJ45
port on that cell. For example, on the HP Integrity rx8620 server shown in following image, if
the operating system instance that must be debugged is installed in nPartition 1, and the core
cell for that nPartition is cell 1, then you must connect the RJ45 connector to cell 1, as shown by
the arrow. Connect one end of the 4-pair CAT-5 cable to the RJ45-to-DB9F converter and the
other end to that debugging port on the server.
Figure 1-10 Debugging port on the rx8620
On the HP Integrity Superdome, connect the 4-pair CAT-5 cable to one of the RJ45 ports shown
in the following image. You can install HP Integrity Superdome cells in two possible orientations:
with ports above the handle or with ports below the handle.
26
Debugging the kernel locally
Figure 1-11 Debugging port on Superdome/sx1000
This figure shows two adjacent cells and the kernel debugging ports on each. Always use the
RJ-45 connector closest to the handle. Only one debug port can be active for a given partition
that spans one or more non-consecutive cells, and you must always connect to the port on the
root cell of that partition.
BL860c/BL870c server blades and rx2800 i2 server
To set up and connect to BL860c/BL870c server blades and rx2800 i2 servers, follow these steps:
Setting up and connecting to the target machine
27
1.
Connect the serial-USB-video cable (or SUV, part number 416003–001, supplied with the
server) to the 9–pin serial connector on the front of the BL860c/BL870c server blade, or back
of the rx2800 i2 server, as shown in the following images.
Figure 1-12 BL860c/BL870c debugging port, front panel
Figure 1-13 rx2800 i2 debugging port, back panel
2.
3.
4.
Connect one end of a null modem cable to the SUV serial port.
Connect the other end of the null modem cable to the laptop, PC, or other blade server acting
as the host.
Because the SUV serial port is shared between the iLO console and the debug serial port,
you must issue the following command at the MP command prompt to direct output to the
debug serial port:
ca –local –mode aux
BL860c i2, BL870c i2, and BL890c i2 server blades
To set up and connect to BL860c i2, BL870c i2, or BL890c i2 server blades, follow these steps:
1.
2.
3.
28
Connect the serial-USB-video cable (or SUV, part number 416003–001 that was supplied
with the server) to the 9–pin serial connector on the front of the BL8x0c i2 server (target).
Connect one end of a null modem cable to the SUV serial port.
Connect the other end of the null modem cable to the laptop, PC, or other blade server acting
as the host.
Debugging the kernel locally
4.
Because the SUV serial port is shared between the iLO console and the debug serial port,
you must issue the following command at the MP command prompt to direct output to the
debug serial port:
ca –local –mode aux
5.
Issue the following command at the Windows command prompt to redirect output to COM2:
bcdedit /dbgsettings serial DEBUGPORT:2 BAUDRATE:115200
6.
Reboot the target system.
Setting up and connecting to the target machine
29
30
2 Debugging the kernel remotely
If you have programmed on the Windows operating system for any length of time, you are
probably familiar with user-mode debuggers and aware of kernel-mode debuggers. User-mode
debuggers help developers to debug applications. Kernel-mode debuggers are used mostly by
driver writers to debug device drivers and by support professionals to analyze system crashes.
This chapter describes how to debug the operating system kernel remotely on HP Integrity
servers. In a remote debugging environment, you are not physically located near the server you
want to debug. You use a host machine, typically a laptop, that has the Windows debugging
software installed on it. You connect the host machine to the server across a LAN and begin the
debugging process.
NOTE: You can use the remote debugging procedures given in this chapter only on the following
servers:
• HP Integrity rx7640 servers
• HP Integrity rx8640 servers
• HP Superdome servers with the sx2000 chipset
If you do not have one of these servers, you must use the local debugging methods described in
Chapter 1.
Overview
A typical remote kernel debugging environment for Windows consists of a host machine (which
runs the debugging software), an Integrity server target machine, and a LAN that provides a
connection between the two. The host is usually a laptop or desktop system with Microsoft
Debugging Tools for Windows (x86) software installed. The target is always an HP Integrity
server for the purposes of this guide.
The following sections provide instructions for setting up the host and target machines. Setting
up the host involves installing the debugging tools. Setting up the target involves adding a boot
configuration option to the operating system, enabling IPMI LAN access and the debugging
option, and, finally, connecting to the server and starting a session.
IMPORTANT: Using the Microsoft Debugging Tools for Windows software to debug kernel
problems is beyond the scope of this document. Debugging the kernel requires deep knowledge
of operating system internals and familiarity with the architecture of the HP Integrity servers.
This is best done by someone with expertise in both areas.
Setting up the host machine
The host is a machine that runs the debugging session. In a typical environment, the host is the
computer that is connected to the target (the machine being debugged) and that runs the debug
tools.
Microsoft provides the Debugging Tools for Windows software, which is a package of extensible
tools for debugging user-mode and kernel-model programs on the Windows family of operating
systems. The Debugging Tools for Windows package contains four debuggers: CDB, NTSD, KD,
and WinDbg.
•
•
Console Debugger (CDB) and NT Symbolic Debugger (NTSD) are console applications
that can debug user-mode programs. These two debuggers are nearly identical except in
the manner in which they are launched.
Kernel Debugger (KD) is a character-based console application that enables in-depth analysis
of kernel-mode activity on all operating systems based on Windows NT. You can use KD (
Overview
31
•
kd.exe) to debug kernel-mode programs and drivers or to monitor the behavior of the OS
itself. KD also supports multiprocessor debugging. Typically, the KD tool runs on the host
but not on the computer being debugged.
Windows Debugger (WinDbg) is a powerful debugging tool capable of both user-mode
and kernel-mode debugging. WinDbg (windbg.exe) provides full source-level debugging
for the Windows kernel, kernel-mode drivers, and system services and for user-mode
applications and drivers. WinDbg can view source code, variables, stack traces, and memory
and can set breakpoints.
Debugging Tools for Windows includes an online help file with detailed documentation on each
tool. See this help file for more information.
Install Debugging Tools for Windows
Versions of the Debugging Tools for Windows package are available for 32-bit x86, native Intel
Itanium, and native x64 platforms. Choose the package version based on the processor of the
host computer. Typically, you would select the Debugging Tools for Windows (x86) 32-bit
package.
x86 Host
If the host uses an x86 processor, always use the 32-bit package.
Itanium Host
If, like the target, the host is Itanium-based — an entry-level HP Integrity
server being used as a development platform, for example — then the
following rules apply:
• To analyze a dump file, use either the 32-bit package or the Itanium
package. It does not matter whether the dump file is a user-mode dump
file or a kernel-mode dump file.
• To perform live kernel-mode debugging, use either the 32-bit package
or the Itanium package. It does not matter that the target is an
Itanium-based machine.
• To perform live user-mode debugging, always use the Itanium package.
It does not matter whether the target is a 64-bit application or a 32-bit
application.
You can install the Debugging Tools for Windows package from the Windows Driver Development
Kit (DDK), Platform Software Development Kit (SDK), or the Customer Support Diagnostics
CD. You can also download the latest release of the package from the Web. The package is
updated frequently. To ensure that you have the most up-to-date tools for the task, obtain the
package from the Web site:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
If you select Custom Install, you can control which features in this package are installed. The
Custom Install options are as follows:
•
•
•
•
32
The Debuggers feature is selected by default. If you leave this selected, installation includes
the debuggers WinDbg, KD, CDB, and NTSD; associated modules, such as DbgHelp; the
symbol server SymSrv; the source server SrcSrv; the dump file tool ADPlus; the remote
debugging tool DbgSrv; and several extension libraries.
The Tools feature and its Helpful Tools subfeature are selected by default. If you leave these
selected, installation includes the tools SymStore, SymChk, DbgRpc, Logger, LogViewer,
KDbgCtrl, DumpChk, GFlags.exe, TList.exe, Kill.exe, List.exe, Breakin.exe,
and UMDH, as well as the remote debugging tools Remote.exe, DbEngPrx, and KdSrv.
The Documentation feature and its Debugging Tools subfeature are selected by default. If
you leave these selected, installation includes the Debugging Tools for Windows
documentation (debugger.chm).
The SDK feature and its subfeatures are not selected by default. If you select these features,
installation includes the headers and libraries necessary to build debugger extensions, several
Debugging the kernel remotely
sample extensions and other samples, the “Debug Help Library” documentation
(dbghelp.chm), and the source server documentation (srcsrv.doc).
After the installation completes, and after you complete the other required tasks, such as preparing
your cable and setting up the target machine, you can launch the Windows Debugger (WinDbg)
by selecting Start > All Programs > Debugging Tools for Windows > WinDbg.
Setting up and connecting to the target machine
To set up the server and initiate remote debugging, complete the following steps:
1. Change the boot configuration.
2. Enable IPMI LAN access and the debugging option.
3. Connect to the target machine and initiate debugging.
Change the boot configuration
To perform kernel-mode debugging, you must enable and configure certain features that are
established when the operating system loads. The settings for these features are included in the
boot options — values that determine how the boot loader loads and configures the operating
system and other bootable programs and devices. Windows Server 2003 and Windows Server
2008 use different mechanisms to store these boot options. Consequently, different procedures
and tools must be used to set or change them.
In systems running Windows Server 2003, you can edit the boot options in Extensible Firmware
Interface (EFI) nonvolatile RAM (NVRAM) in two ways, using different tools:
•
•
Bootcfg (bootcfg.exe) is a command-line tool that enables you to edit boot options while
the operating system is running. You can use Bootcfg to add, delete, and change the values
of all valid boot options. You can also use Bootcfg commands in a script or batch file to set
boot options or to reset them after you replace or upgrade an operating system.
Nvrboot (nvrboot.efi) is an EFI-based boot entry editor that you can run when the
operating system is shut down. Nvrboot edits boot entries and includes commands to export
backup copies of boot entries and to import backup copies of boot entries into NVRAM.
You can access Nvrboot from the EFI Shell in the msutil directory of the system partition
(fsN:/msutil/nvrboot.efi, where N is the number of the file system).
In systems running Windows Server 2008, you must edit the boot options with a different tool:
•
BCDEdit (bcdedit.exe) is a command-line tool for adding, deleting, editing, and modifying
boot data in a boot configuration data (BCD) store. The usage information provided below
is a quick summary of some of the main features. For a complete description of all arguments
and parameters, refer to the Microsoft documentation found here:
http://technet.microsoft.com/en-us/library/cc709667(WS.10).aspx
Windows Server 2003 Systems Only ⇒ Option 1: Using Bootcfg (recommended)
To edit boot options using the Bootcfg tool, complete the following steps:
Setting up and connecting to the target machine
33
1.
At the command-line prompt, enter the following command:
C:\>bootcfg
The current boot configuration appears, as shown in the following example:
Boot Options
-----------Timeout: 20
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
CurrentBootEntryID: 1
Boot Entries
-----------Boot entry ID: 1
OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID: 2
OS Friendly Name: Internal Bootable DVD
Boot entry ID: 3
OS Friendly Name: EFI Shell [Built-in]
In this example, you can see that “Boot entry ID 1” is the default Windows boot option. It
has only the out-of-band management (EMS or SAC prompt) configured as an option (the
“redirect” option). On some systems, the NOVESA option is listed here, too.
You must add a couple of options to enable live debugging. Make a copy of the boot entry
and then add the options.
2.
Make a copy of the default boot entry by issuing the following command:
C:\>bootcfg /copy /d “Windows Server 2003, Enterprise with Debugging
Enabled” /id 1
The system indicates that it successfully copied boot entry “1.”
The new entry is copied to the bottom of the list and becomes the last entry. Because the
previous example contains only three boot entries, the new boot entry is assigned “ID 4”
(remember, this is only an example; if your system has more boot options, your ID number
will be higher).
3.
Issue the bootcfg command again to see the new boot entry ID 4:
C:\>bootcfg
The new boot configuration appears:
Boot Options
-----------Timeout: 20
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
CurrentBootEntryID: 1
Boot Entries
-----------Boot entry ID: 1
34
Debugging the kernel remotely
OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID: 2
OS Friendly Name: Internal Bootable DVD
Boot entry ID: 3
OS Friendly Name: EFI Shell [Built-in]
Boot entry ID: 4
OS Friendly Name: Windows Server 2003, Enterprise with Debugging Enabled
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry 4 is the same as boot entry 1 except for the description (or operating
system-friendly name).
4.
Add the Debug and Baud options to boot entry 4 by executing the following command:
C:\>bootcfg /debug on /baud 115200 /id 4
The system indicates that the operating system load options were changed for boot entry
ID 4.
In this example, the baud rate is configured at 115200. If your laptop does not support this
speed, try a different value, such as 38400. Remember to use the same value in the kernel
debugger where appropriate.
Setting up and connecting to the target machine
35
5.
To confirm that the entries were added correctly, run the bootcfg command again:
C:\>bootcfg
The new boot configuration appears:
Boot Options
-----------Timeout: 20
Default:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
CurrentBootEntryID: 1
Boot Entries
-----------Boot entry ID: 1
OS Friendly Name: Windows Server 2003, Enterprise
OsLoadOptions: /redirect
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efiOsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID: 2
OS Friendly Name: Internal Bootable DVD
Boot entry ID: 3
OS Friendly Name: EFI Shell [Built-in]
Boot entry ID: 4
OS Friendly Name: Windows Server 2003, Enterprise with Debugging Enabled
OsLoadOptions: /redirect /debug /baudrate=115200
BootFilePath:
\Device\HarddiskVolume1\EFI\Microsoft\WINNT50\ia64ldr.efi
OsFilePath:
\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume1\WINDOWS
Boot entry ID 4 now shows the debug and baud rate switches. As mentioned previously, a
COM port entry is not required for HP Integrity servers.
Windows Server 2003 Systems Only ⇒ Option 2: Using Nvrboot
To edit boot options using the Nvrboot tool, complete the following steps:
1.
From the EFI shell, navigate to the MSUTIL directory and execute the NVRBOOT.EFI
command, as shown here:
fs1:\> dir
Directory of: fs1:\
03/25/03 05:00a 841,216 SETUPLDR.EFI
06/25/03 11:14a <DIR> 1,024 EFI
06/25/03 11:14a <DIR> 1,024 MSUtil
2 File(s) 841,343 bytes
2 Dir(s)
fs1:\> cd msutil
fs1:\MSUtil> nvrboot
2.
36
Select M(Modify) to modify the operating system boot loader.
Debugging the kernel remotely
3.
At the Enter OS boot option to modify: prompt, select the first boot option by
entering: 1. The system displays the following:
1 LoadIdentifier = Windows Server 2003, Datacenter
2 OsLoadOptions = /REDIRECT /NOVESA
3 EfiOsLoaderFilePath = cf5f2ddc-b885-11d7-b831-000000000000 ::
\efi\microsoft\winnt50\ia64ldr.efi
4 OsLoaderFilePath = e605a034-b885-11d7-b831-000000000000 :: \windows
Enter VAR to modify: 2
4.
5.
At the Enter VAR to modify: prompt, select the second variable to modify
(OsLoadOptions) by entering: 2.
Reenter the OsLoadOptions variable, this time adding the /DEBUG and /BAUDRATE switches,
as follows:
OsLoadOptions=/REDIRECT /NOVESA /DEBUG /BAUDRATE=115200
NOTE: The /NOVESA switch is needed only on cell-based servers running Windows Server
2003 without SP1 and with a VGA card installed in the nPartition.
6.
Verify that the change was made by repeating step 1 through step 3. The system displays
the following:
1 LoadIdentifier = Windows Server 2003, Datacenter
2 OsLoadOptions = /REDIRECT /NOVESA /DEBUG /BAUDRATE=115200
3 EfiOsLoaderFilePath = cf5f2ddc-b885-11d7-b831-000000000000 ::
\efi\microsoft\winnt50\ia64ldr.efi
4 OsLoaderFilePath = e605a034-b885-11d7-b831-000000000000 :: \windows
7.
After verifying the changes to the OsLoadOptions variable, exit and boot the operating
system.
After debugging is complete, remove the /DEBUG and /BAUDRATE=115200 switches from the
boot configuration OsLoadOptions variable and reboot the operating system.
Windows Server 2008 Systems Only ⇒ Using BCDEdit
The values you assign with this tool depend on the type of connection you are trying to make
with the target system. At any time from the command line you can enter the following commands
to see the online help regarding tool usage:
bcdedit /?
or
bcdedit /dbgsettings /?
To enable debugging for a typical serial connection in Windows Server 2008, complete the
following steps:
1.
Make a copy of the default boot entry by issuing the following command:
C:\>bcdedit /copy {identifier_of_boot_entry_to_be_copied} /d
“original non-debug boot entry”
The system indicates that it successfully copied the boot entry with a new description.
2.
Set the connection type and baud rate for the debugger:
C:\>bcdedit /dbgsettings SERIAL BAUDRATE:115200
Setting up and connecting to the target machine
37
3.
Enable the debugger for the desired boot entry:
C:\>bcdedit /debug
{identifier_of_boot_entry_targeted_for_kernel_debugging} ON
For a complete description this tool, refer to the Microsoft documentation found here:
http://technet.microsoft.com/en-us/library/cc709667(WS.10).aspx
Enable IPMI LAN access and the debugging option
Enable the Windows debugging option and enable LAN access to the management processor
(MP) by completing the following steps:
1.
2.
3.
Log in to the server’s MP.
Issue an SA command to display MP access parameters.
Enter G to enable the Windows debug client, and y to confirm. The system displays the
following:
[manic] MP:CM> sa
This command displays and allows modification of access parameters.
T - Telnet access : Enabled
H - Secure Shell access : Enabled
N - Network Diagnostics : Disabled
D - DIAG Menu : Disabled
I- IPMI Lan access : Disabled
G - Windows Debug Client : Disabled
A - HP SIM Identification : Disabled
Select access mode to change : g
Are you sure you want to enable the Windows Debug ports(Y/N) ? : y
Windows Debug enabled for new connections for 1 hour.
This enables the debug port for 1 hour, complexwide, for every partition, so you can have
multiple kernel debugging sessions active at the same time if you want. When a debug
session is started on a partition, it remains active until the session is disconnected, irrespective
of the 1–hour timer. The timer for the debugging port is only used for new connections and
debugging sessions.
4.
If IPMI access is currently disabled, enter I to enable it, and y to confirm.
Connect with the target machine and initiate debugging
Now you must connect to the Windows debugger using the WinDbg command with the -k
option.
Enter the WinDbg command using the following format:
WinDbg -k com:port=<MP IP address or hostname>,ipport=<port number of
partition>
where:
<IP address or hostname> is the server MP IP address or host name, and <port number
of partition> is the output port number having the format 472nn, with nn as the partition
number (partition number 1 = 01, partition number 2 = 02, and so on).
For example, to connect to the debug output of partition number 3 on the server named manic,
enter the following command:
WinDbg -k com:port=manic.hp.com,ipport=47203
38
Debugging the kernel remotely
3 Debugging HP Virtual Machines guests
HP Virtual Machines (HPVM) is a soft partitioning and virtualization technology that provides
operating system isolation with CPU allocation and shared I/O. HPVM enables a single Integrity
server to emulate multiple virtual machines running distinct operating systems and environments.
The Virtual Machines solution consists of two components:
• A VM host (the physical system on which the virtual machines reside)
• One or more virtual machines, also known as guests
Virtual machines, or guests, are abstractions of real, physical machines. They are fully-loaded,
operational systems, complete with operating system, system management utilities, applications,
and networks, all running in the virtual machine environment that you set up for them. You
boot and manage guests using the same storage media and procedures that you would if the
guest operating system were running on its own dedicated physical hardware platform.
HPVM Windows guest debug process
HPVM Version 2.0 supports Windows kernel debugging through the host serial ports. Usually
only one such port is available on low-end systems. Therefore, without an add-in serial port
card, you can debug only one Windows guest at a time. To debug multiple guests on low-end
systems (or even a single guest on mid-range or high-end systems, such as rx7640, rx8640, and
Superdome), you need a serial port card.
To enable kernel debugging for an HPVM Windows guest, complete the following steps:
1. Locate the target guest’s configuration file: vmm_config.current (the host maintains all
per-guest information in the /var/opt/hpvm/guests/$guest_name$ directory).
2. Open the vmm_config.current file and add the following lines to it:
# Debugging uart definition
uart(7,1)=/dev/ttyXX
where XX is the tty belonging to the available host serial port.
NOTE: The instructions above are for debugging locally over the serial port. To debug
over a LAN, you would add the following line to the guest configuration file instead:
tunable = 0xNNNNNNNN wdbg
where NN NN NN NN is the static IP address (in hex) of the desired debug port.
3.
Reboot the guest to apply the change (unless it is already off).
Each guest can have only one such entry, but each guest on a given host can attach to a unique
tty port to enable multiguest debugging. The procedure for physically connecting to the host
machine is identical to the local debugging connection methods used on other Integrity servers
(see Chapter 1). The debugger simply attaches to a given serial port on the host using a
null-modem cable.
Also, you must modify the Windows guest boot entry in the virtual EFI shell the same way that
you do when debugging entire Integrity servers, as described in previous chapters. The only
restriction is that you must use a baud rate of 38400bps. You must specify this in the NVRAM
boot entry for the operating system and in the kernel debugger configuration of the debugger
machine.
HPVM Windows guest debug process
39