On 10/8/2014 3:24 PM, joaoandrefe...@sapo.pt wrote:
<snip >
>
> Thank you so much. I'm getting improvements. Running "./kdmx -n -d
> -p/dev/ttyS0 -b115200 -DtT" ouputs:
>
> serial port: /dev/ttyS0
> Initalizing the serial port to 115200 8n1
> /dev/pts/0 is slave pty for for terminal emulator
> /dev/pts/1 is slave pty for gdb
> t> hello world 0x0d
>
> And then I've tried "./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS", as you
> suggested:
>
> serial port: /dev/ttyS0
> Initalizing the serial port to 115200 8n1
> /dev/pts/0 is slave pty for for terminal emulator
> /dev/pts/1 is slave pty for gdb
>
> s> hello world 0x0d
>
> (I typed "hello world <enter>" on the minicom console, on both cases). So, it
> seems the
> communication between both kdmx <-> minicom and kdmx <-> serial port to the
> target is
> working properly. But it isn't strange that you can't see what you're typing
> in the
> minicom console? This happened to you before?
In the part above that I < snipped >, you reported that minicom is now working.
But if minicom is working then kdmx -DtT and kdms -DsS should show what you
type in minicom going from minicom to the host serial port and then returning
in the opposite direction. The two kdmx examples you show here do not have the
data returning from the host serial port toward minicom.
That is showing a problem. Each character that you type in minicom, minicom
writes
to the terminal emulator pty, kdmx reads from the terminal emulator pty, kdmx
sends
to the host serial port, across the cable, into the target serial port. On the
target, *** the serial port should be the console ***, and a shell should have
the
target serial port open, the shell reads the character.
The shell on the target serial port should echo each character as it arrives,
writing to the target serial port, across the cable, to the host serial port,
kdmx
reads from the host serial port, kdmx writes to the terminal emulator pty,
minicom reads from the terminal emulator pty and displays the echoed character.
It appears that kdmx is not reading any echoed character from the host serial
port. The above does not prove whether the target received the character and
whether it echoed it.
Is the target console on the target serial port?
Is there a shell connected to the target serial port?
If the answer is yes to both of those questions, then you should be
able to terminate kdmx and connect minicom directly to the host
serial port to test that the target serial port is working
correctly. In this case, you should have normal shell access
on the target via minicom running on the host.
If the answer is no to either of those questions, you need to
fix that problem.
Also, can you email me your target .config? (No need to cc
the list.)
> My version of your last example:
>
> 1. First, typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"
That echo command should be visible in the kdmx debug output below
in "0.1. Output for kdmx:", but it is not there.
> 2. Then, in GDB: target remote /dev/pts/5
> 3. Again in minicom: "echo "target running again" <enter>"
>
> 0.1. Output for kdmx:
> $ ./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS
> serial port: /dev/ttyS0
> Initalizing the serial port to 115200 8n1
> /dev/pts/1 is slave pRemote debugging using /dev/pts/5
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the output from gdb to stdout that results
from the gdb command: target remote /dev/pts/5
I do not know how output from gdb to stdout would
appear in the window that kdmx is running in.
You reported that gdb command as step 2 of
your test.
^^^^^^^^^^^^^^^^^^^^^
part 1 of the kdmx output
reporting terminal emulator pty
(see below for part 2)
> Ignoring packet error, continuing...
> warning: unrecognized item "timeout" in "qSupported" response
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Malformed response to offset query, timeout
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And these 9 lines are also output from gdb to stdout
that result from the gdb target remote command.
You show this same data below as "0.2. Output for GDB:".
Is this appearance of the gdb stdout data a cut and
paste error when you created the email, or did it
actually appear in the window that kdmx was running in?
> ty for for terminal emulator
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
part 2 of the kdmx output
reporting terminal emulator pty
> /dev/pts/5 is slave pty for gdb
>
> s> echo g >/proc/sysrq-trigger 0x0d
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You report this as step 1 of your test.
> +$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25$qSupported:xmlRegisters=i386;qRelocInsn+#25---+$Hg0#df$Hg0#df$Hg0#df$Hg0#df---+$?#3f$?#3f$?#3f$?#3f---+$Hc-1#09$Hc-1#09$Hc-1#09$Hc-1#09---+$qC#b4$qC#b4$qC#b4$qC#b4---+$qAttached#8f$qAttached#8f$qAttached#8f$qAttached#8f---+$qOffsets#4b$qOffsets#4b$qOffsets#4b$qOffsets#4b--e-+read()
> of gdb pty returned EIO,
This is the queries from gdb to the target that are triggered by
the target remote command. There appears to be no response from
the target. gdb eventually times out.
> closing and re-opening gdb pty.
> EIO is expected if gdb closed the connection.
> /dev/pts/0 is slave pty for gdb
> gdb slave pty path is unchanged
> echo "target running again" 0x0d
>
> 0.2. Output for GDB:
>
> Remote debugging using /dev/pts/5
> Ignoring packet error, continuing...
> warning: unrecognized item "timeout" in "qSupported" response
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Malformed response to offset query, timeout
>
> So, it seems GDB is not working well. Can you reach a solid conclusion based
> on this?
>
>>
>>> trying almost all of them and searching for minicom tutorials online, I'm
>>> not progressing on this. Sorry for this (another) rookie doubt, I'm also on
>>> a race against time but I can't seem to figure this out.
>>>
>>>>> Host window #3 (GDB):
>>>
>>> GDB seemed to be running good before (using kdmx, when connecting directly
>>> to /dev/ttyS0), now is giving the errors below.
>>>
>>> (at kernel source tree):
>>>
>>> $ gdb /boot/vmlinux
>>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2)
>>> Copyright (C) 2010 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "i686-redhat-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /boot/vmlinux...done.
>>> (gdb) set remotebaud 115200
>>> (gdb) target remote /dev/pts/3
>>
>> You can not use the target remote command until the "Entering KGDB"
>> message prints on the console. This message is the result of either
>> the kgdbwait kernel command li./kdmx -n -d -p/dev/ttyS0 -b115200 -DtT
>> command to /proc/sysrq-trigger (see "host window 2 - terminal emulator"
>> in my example above).
>>
>> What is probably happening here is that gdb is talking to the shell
>> on the target. You can see this if you use either -DsS or -DgG as
>> a kdmx option.
>>
>
> Yes, I was not expecting GDB to work, because of the issue with minicom.
> However, currently I have the "kgdbwait" option in the kernel boot options,
> which means that I have the target hanged on the "kgdb: Waiting for
> connection from remote gdb..." screen.
Where do you see the "kgdb: Waiting for connection from remote gdb..."
message? This is where your console is.
You should be seeing this message in your minicom. If you are instead
seeing it on a video monitor connected to your target, then your
console is in the wrong place.
>
> EDIT 4: I removed kgdbwait again, and so I have the target OS booted till the
> end.
< snip >
------------------------------------------------------------------------------
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
