All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: xen-devel@lists.xensource.com, Christian Tramnitz <chris.ace@gmx.net>
Subject: Re: debugging Xen in a serial-less environment
Date: Fri, 06 Mar 2009 11:33:32 -0800	[thread overview]
Message-ID: <49B17A8C.90706@goop.org> (raw)
In-Reply-To: <49AF9E92.5060207@redhat.com>

Gerd Hoffmann wrote:
> Christian Tramnitz wrote:
>   
>> I'm currently trying to debug a couple of iommu issues I'm experiencing
>> on a X58 board with VT-d while passing through hardware into a Windows
>> HVM domU, but unfortunately it seems legacy hardware was deemed obsolete
>> and not a single serial port is provided by the board (Asus P6T Deluxe
>> for that matter).
>>
>> Are there any alternatives to the Xen console on serial or vga?
>>     
>
> Does the box have AMT?  The you can use serial-over-lan.

There's the USB debug port stuff which got added to the kernel a while 
ago.  Looks like it shouldn't be too hard to graft into Xen.

    J

Mini-HOWTO for using the earlyprintk=dbgp boot option with a
USB2 Debug port key and a debug cable, on x86 systems.

You need two computers, the 'USB debug key' special gadget and
and two USB cables, connected like this:

  [host/target] <-------> [USB debug key] <-------> [client/console]

1. There are three specific hardware requirements:

 a.) Host/target system needs to have USB debug port capability.

 You can check this capability by looking at a 'Debug port' bit in
 the lspci -vvv output:

 # lspci -vvv
 ...
 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
         Subsystem: Lenovo ThinkPad T61
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 0
         Interrupt: pin D routed to IRQ 19
         Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
         Capabilities: [50] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME+
         Capabilities: [58] Debug port: BAR=1 offset=00a0
                            ^^^^^^^^^^^ <==================== [ HERE ]
	 Kernel driver in use: ehci_hcd
         Kernel modules: ehci-hcd
 ...

( If your system does not list a debug port capability then you probably
  wont be able to use the USB debug key. )

 b.) You also need a Netchip USB debug cable/key:

        http://www.plxtech.com/products/NET2000/NET20DC/default.asp

     This is a small blue plastic connector with two USB connections,
     it draws power from its USB connections.

 c.) Thirdly, you need a second client/console system with a regular USB port.

2. Software requirements:

 a.) On the host/target system:

    You need to enable the following kernel config option:

      CONFIG_EARLY_PRINTK_DBGP=y

    And you need to add the boot command line: "earlyprintk=dbgp".
    (If you are using Grub, append it to the 'kernel' line in
     /etc/grub.conf)

    NOTE: normally earlyprintk console gets turned off once the
    regular console is alive - use "earlyprintk=dbgp,keep" to keep
    this channel open beyond early bootup. This can be useful for
    debugging crashes under Xorg, etc.

 b.) On the client/console system:

    You should enable the following kernel config option:

      CONFIG_USB_SERIAL_DEBUG=y

    On the next bootup with the modified kernel you should
    get a /dev/ttyUSBx device(s).

    Now this channel of kernel messages is ready to be used: start
    your favorite terminal emulator (minicom, etc.) and set
    it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to
    see the raw output.

 c.) On Nvidia Southbridge based systems: the kernel will try to probe
     and find out which port has debug device connected.

3. Testing that it works fine:

   You can test the output by using earlyprintk=dbgp,keep and provoking
   kernel messages on the host/target system. You can provoke a harmless
   kernel message by for example doing:

     echo h > /proc/sysrq-trigger

   On the host/target system you should see this help line in "dmesg" output:

     SysRq : HELP : loglevel(0-9) reBoot Crashdump terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)

   On the client/console system do:

       cat /dev/ttyUSB0

   And you should see the help line above displayed shortly after you've
   provoked it on the host system.

If it does not work then please ask about it on the linux-kernel@vger.kernel.org
mailing list or contact the x86 maintainers.

  reply	other threads:[~2009-03-06 19:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-04 21:43 debugging Xen in a serial-less environment Christian Tramnitz
2009-03-04 21:50 ` Dugger, Donald D
2009-03-05  9:42 ` Gerd Hoffmann
2009-03-06 19:33   ` Jeremy Fitzhardinge [this message]
2009-03-07  8:50     ` Christian Tramnitz
2009-03-07  9:48       ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B17A8C.90706@goop.org \
    --to=jeremy@goop.org \
    --cc=chris.ace@gmx.net \
    --cc=kraxel@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.