On 10/13/2014 10:34 AM, joaoandrefe...@sapo.pt wrote:
> Citando Frank Rowand <frowand.l...@gmail.com>:
< snip >
> Hello again, Frank,
>
> I added the "console=ttyS0,115200n8" option you mentioned in the
> target kernel boot line, and then rebooted the target. When CentOS
> finished booting on the target, I started both kdmx ("./kdmx -n -d
> -p/dev/ttyS0 -b115200 -DsS") and minicom ("minicom -o -w -p
> /dev/pts/1") on the host. Then I rebooted the target again, and kdmx
> started receiving input from target (output below). From what I was
> able to see, it seems minicom received the same information
> (excluding the "0x0d" and "0x0a" chars at the end of each line). When
That is an excellent result. For the -D debug option, kdmx reports any
unprintable character as a hex sequence. 0x0d is carriage return,
0x0a is new line. Minicom simply does the carriage return and new
line, so you do not see "0x0d 0x0a" in minicom.
> the target reached the GRUB screen (and after choosing to boot the
> target kernel), kdmx received an error (last line on the output
> below) and exited, which of course made minicom execution fail. Can I
> consider the fact of kdmx and minicom getting input from the target
> as an improvement?
Yes. The reason that kdmx thinks that the read fails is that the
data from the serial port is 0xff (decimal -1) and kdmx incorrectly
perceives that as an error. I will send you a patch to kdmx in a
following email that should fix the problem. If you don't want to
apply the patch and recompile kdmx, then you should be able to just
restart kdmx after it exits.
>
> Also, I have a conceptual question for you. Isn't it strange that in
> order to run KGDB I'll have to have 2 ports open at the host side
> (with kdmx), and only one at the target? If I only had one port at
> each end (like I had in the beggining, prior to using kdmx), wouldn't
> that work locally (on the target)? I have both host and target
> physically side by side, so if the information about debugging stood
> on the target, I think that wouldn't be a problem for me. Maybe what
> I'm asking is only a silly question, but I didn't fully comprehend
> the theory sorrounding this, and it is a bit frustrating that it
> seemed that the initial setup was working, since traget hanged on
> boot, and I was able to resume it from GDB.
On the target system, there are two things writing out to the
console serial port. First is everything from printk(), so all of
the messages from the kernel. That includes things like:
> s< Stopping certmonger: [ OK ] 0x0d 0x0d 0x0a
> Stopping atd: [ OK ] 0x0d 0x0d 0x0a
> Stopping cups: [ OK ] 0x0d 0x0d 0x0a
> Stopping abrt daemon: [ OK ] 0x0d 0x0d 0x0a
> Shutting down postfix: [ OK ] 0x0d 0x0d 0x0a
> Stopping crond: [ OK ] 0x0d 0x0d 0x0a
> Stopping automount: [ OK ] 0x0d 0x0d 0x0a
kdmx reads these messages from the host serial port and
sends them to the terminal emulator pty. So minicom,
connected to the terminal emulator pty will see the
normal console output from the kernel.
When you trigger kgdb on the target (either echoing g to
/proc/sysrq-trigger, or when the kgdbwait command line
option is processed) then the debugging stub in the
kernel starts listening on the host console serial port.
When you issue the "remote target" command in gdb, gdb
starts sending commands and requests to the kdmx pty,
kdmx sends the commands and requests over the serial
port to the target, and the debugging stub read them.
The debugging stub responds to the commands and
requests over the console serial port, kdmx knows that
gdb is waiting for a response and is able to determine
that the response is of the proper format that gdb is
expecting, so it forwards the response to gdb. kdmx is
able to determine whether the data from the target
console appears to be a response to gdb or normal
console output and thus routes the data either to
gdb or to the terminal emulator.
If you connected gdb directly to the host serial
port then gdb would see all of the normal console
output messages, as well as the target debugging
stub replies, and gdb would become rather confused
because it is not expecting the console output.
< snip >
-Frank
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
