Citando Frank Rowand <frowand.l...@gmail.com>:
On 10/9/2014 10:54 AM, joaoandrefe...@sapo.pt wrote:
Citando Frank Rowand <frowand.l...@gmail.com>:
On 10/9/2014 7:51 AM, joaoandrefe...@sapo.pt wrote:
Citando Frank Rowand <frowand.l...@gmail.com>:
On 10/8/2014 3:24 PM, joaoandrefe...@sapo.pt wrote:
< snip >
Disclaimer #1: Yes, it seems my copy-pasted output is all messed up.
I don't know if it was my tiredness or just Firefox, unfortunately
I've just delayed even more my work.
It happens. Life sucks. We move on.
Disclaimer #2: I wasn't running anything on the target, so the last
example would never work. Sorry also for that. Because your previous
examples (before you started debugging with kdmx) relied on 3
different windows on the host, I wasn't accurate enough to completely
understand your last example.
Now, I've connected on the target to
its serial port (/dev/ttyS0), through PuTTY.
Does this mean you are running PuTTY on the host system, connected
to the /dev/ttyS0 on the host system?
Do not run PuTTY. You are running minicom to access the console.
When you run PuTTY on the host, connected to the host /dev/ttyS0,
then there are two programs reading from /dev/ttyS0: PuTTY and
kdmx. The data coming across the cable will be split between
the two programs, some goint to PuTTY and some going to kdmx.
kdmx does not get all of the traffic that is supposed to go to
kgdb, so kgdb gets rather confused.
I'm running PuTTY on the target system, i. e., on the other side of
the host's serial cable. Regarding your scheme, in a previous
message:/home/cloud/Desktop
---------------------- HOST
-------------------------------------- --- TARGET
---
terminal <----> /dev/pty/29 <----> +------+
emulator | |
| kdmx | <----> serial port
<== cable ==> target console
gdb <---------> /dev/pty/53 <----> | | /dev/ttyUSB0
+------+
I'm running PuTTY on the TARGET (scheme), as the "target console".
Maybe this is not what is supposed to happen, but it was the idea I
Ah, that is yet a different picture than I was understanding.
That is wrong and will not work.
"target console" on the target is the serial device. The kernel on
the target should be printing the boot messages to this device, and
at the end of boot either a shell show be attached to this device
or a login prompt to enter a shell should appear on this device.
You probably select the console device by describing it on the
kernel boot line (the same place where you put "kgdbwait").
When the target console is set to the serial device, you
will see the console traffic on minicom on the host. Be
sure to start kdmx and minicom before booting so you can
see the boot messages.
One interesting detail is that I ran things in the order you mentioned
above ("./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS" and "minicom -o -w -p
/dev/pts/1" on the host, and then booting the kernel to be debugged in
the target - without PuTTY), and I got the following output @ kdmx:
serial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/1 is slave pty for for terminal emulator
/dev/pts/2 is slave pty for gdb
s< 0x00
This "s< 0X00" isn't coming from the target, or am I wrong?
**********************************************************
What is in your current kernel boot line?
**********************************************************
My current kernel boot line is below (I've also attached the file
where it is defined, /boot/grub/menu.lst). This is where I also had
the "kgdbwait" option, which I removed since then. I thought kgdboc
was the option to use in order to get the target communicating with
the host. When I had the "kgdbwait" option, the kernel hanged during
boot, and when I entered the "cont" command on GDB (on the host, of
course after running "target remote"), the kernel would continue
booting till the end. Now, unfortunately, nothing is happening.
title CentOS (2.6.32.4-custom2)
root (hd0,0)
kernel /vmlinuz-2.6.32.4-custom2 ro
root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8
rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16
KEYBOARDTYPE=pc KEYTABLE=pt-latin1 rd_LVM_LV=vg_centos6/lv_root
rd_NO_DM kgdboc=ttyS0,115200 rhgb quiet crashkernel=auto
initrd /initrd-2.6.32.4-custom2.img
got from your previous email. If it isn't PuTTY, what should be? A
normal Linux terminal? Minicom? By the way, prior to that email of
yours, I had the target system simply running the OS "normally",
idle, without anything "special" running to acknowledge the serial
connection (and even beforeserial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/3 is slave pty for for terminal emulator
/dev/pts/4 is slave pty for gdb that I had the kgdbwait option set, so
the kernel stopped booting and expected a connection from GDB).
So PuTTY is intercepting all of the traffic from the host. This
traffic needs to go into the target kernel. If the target console
is set to the serial device then this would happen.
The "kgdb: Waiting for
connection from remote gdb..." message was of course the target
hanged up on boot because of the kgdbwait boot kernel option, which I
have removed.
Also, regarding your questions:
Is the target console on the target serial port?
Is there a shell connected to the target serial port?
What I've done is what I've explained above, so I can't seem to
differentiate both questions. I have the port open in PuTTY, and
that's all. Should I have minicom running on the target also? Sorry,
all of this is kind of new for me...
I've just recreated that last example again. Details below:
1.1 - First, run kdmx with "./kdmx -n -d -p/dev/ttyS0 -b115200 -DtT":
If my hints in this email do not work, then please change "-DtT" to -DsS
for step 1.1. And also send me the kernel command line that prints on
the console near the beginning of the boot messages of the target.
I've changed the option in step 1.1. Now I have:
1.1 - "./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS"
serial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/3 is slave pty for for terminal emulator
/dev/pts/4 is slave pty for gdb
1.2 - "minicom -o -w -p /dev/pts/3"
1.3 - @ GDB: "set remotebaud 115200"
1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"1.1 -
"./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS"
serial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/3 is slave pty for for terminal emulator
/dev/pts/4 is slave pty for gdb
1.2 - "minicom -o -w -p /dev/pts/3"
1.3 - @ GDB: "set remotebaud 115200"
1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"
@ kdmx: s> echo g >/proc/sysrq-trigger 0x0d
@ PuTTY (on target system): echo g>/proc/sysrq-trigger
You need to see the message on the target console that says it
is waiting for kgdb before typing the gdb target remote command.
In this case, the waiting for kgdb message does not appear because
the target kernel never got the "echo g >/proc/sysrq-trigger 0x0d"
command, since PuTTY instead got it.
If the target console was properly set to the serial port and
PuTTY was not running on the target, then the target kernel would
write the waiting for kgdb message to the target serial port, then
it would come through kgdb to the terminal emulator, and you would
see it in minicom.
I think I got it. Now I'll just have to understand what's wrong on the
target and change things accordingly.
< snip >
< the info that was below was helpful in confirming stuff, thanks >
-Frank
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_centos6-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32.4-custom2)
root (hd0,0)
kernel /vmlinuz-2.6.32.4-custom2 ro root=/dev/mapper/vg_centos6-lv_root
rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD
SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=pt-latin1
rd_LVM_LV=vg_centos6/lv_root rd_NO_DM kgdboc=ttyS0,115200 rhgb quiet
crashkernel=auto
initrd /initrd-2.6.32.4-custom2.img
title CentOS (2.6.32-431.29.2.el6.i686)
root (hd0,0)
kernel /vmlinuz-2.6.32-431.29.2.el6.i686 ro
root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8
rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16
KEYBOARDTYPE=pc KEYTABLE=pt-latin1 rd_LVM_LV=vg_centos6/lv_root rd_NO_DM rhgb
quiet crashkernel=auto
initrd /initramfs-2.6.32-431.29.2.el6.i686.img
title CentOS (2.6.32-431.el6.i686)
root (hd0,0)
kernel /vmlinuz-2.6.32-431.el6.i686 ro
root=/dev/mapper/vg_centos6-lv_root rd_NO_LUKS LANG=en_US.UTF-8
rd_LVM_LV=vg_centos6/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16
KEYBOARDTYPE=pc KEYTABLE=pt-latin1 rd_LVM_LV=vg_centos6/lv_root rd_NO_DM rhgb
quiet
initrd /initramfs-2.6.32-431.el6.i686.img
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
