Citando Frank Rowand <frowand.l...@gmail.com>:
> On 10/8/2014 4:21 AM, joaoandrefe...@sapo.pt wrote: >> Citando Frank Rowand <frowand.l...@gmail.com>: >> >>> On 10/7/2014 1:27 PM, Frank Rowand wrote: > > < snip > > >>> >>> Here is an example, where I am using a USB serial port to connect between >>> my host and target. I did all of the commands in "host window 1" before >>> I did the commands in "host window 2". I did all of the commands in >>> "host window 2" before I did the commands in "host window 3". >>> >>> >>> ---------------------- HOST >>> -------------------------------------- --- TARGET >>> --- >>> >>> terminal <----> /dev/pty/29 <----> +------+ >>> emulator | | >>> | kdmx | <----> serial >>> port <== cable ==> target console >>> gdb <---------> /dev/pty/53 <----> | | /dev/ttyUSB0 >>> +------+ >>> >>> >>> >>> ----- host window 1 - kdmx ----- >>> >>> $ export PS1='[1]: ' >>> [1]: ./kdmx -n -d -p/dev/ttyUSB0 -b115200 >>> serial port: /dev/ttyUSB0 >>> Initalizing the serial port to 115200 8n1 >>> /dev/pts/29 is slave pty for for terminal emulator >>> /dev/pts/53 is slave pty for gdb >>> >>> >>> ----- host window 2 - terminal emulator ----- >>> # In this example, I am using the sysrq debug command instead of the >>> # kernel command line 'kgdbwait' option to enter kgdb >>> >>> $ export PS1='[2]: ' >>> [2]: minicom -o -w -p /dev/pts/29 >>> >>> # Now in minicom, connected to the target console. >>> # CONFIG_PRINTK_TIME=y, so timestamps will be added to >>> # printk() messages to the console. > > # I left these minicom messages out before. Adding now so you can > # compare your minicom to mine. > > Welcome to minicom 2.5 > > OPTIONS: I18n > Compiled on May 2 2011, 10:05:24. > Port /dev/tty8 > > Press CTRL-A Z for help on special keys > As I said on the reply to the other thread (which can be seen in the screenshot attached there), apart from the version number, compilation date and port, this seems to be exactly what I see, with the difference that I can't type anything. This is puzzling me a lot, and delaying my (urgent) work. I installed Minicom through yum, and I've already tried to install versions 2.7 (latest to date) and 2.6.2 from the respective sources, but I'm having errors during compilation time, which I found (after googling a bit) that are strangely usual with both versions. However, I will try to install version 2.5 and let you know. EDIT 1: it seems is no longer necessary, as minicom is producing output. > >>> >>> $ export PS1='% ' >>> % cat /proc/version >>> Linux version 3.17.0-dirty (frank@ussvlx) (gcc version >>> 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Mon Oct >>> 6 10:19:37 PDT 2014 >>> % echo g >/proc/sysrq-trigger >>> [ 24.246292] SysRq : DEBUG >>> [ 24.247184] Entering KGDB >>> >>> >>> ----- host window 3 - gdb ----- >>> # current directory is the root of the kernel source tree >>> >>> $ export PS1='[3]: ' >>> [3]: hostname >>> ussvlx >>> [3]: whoami >>> frank >>> [3]: pwd >>> /xxx/git_linus/linux--3.17 >>> [3]: echo $KBUILD_OUTPUT >>> ../build/dragon_linus_3.17 >>> [3]: strings $KBUILD_OUTPUT/vmlinux | grep "^Linux version" >>> Linux version 3.17.0-dirty (frank@ussvlx) (gcc version >>> 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Mon Oct >>> 6 10:19:37 PDT 2014 >>> Linux version >>> [3]: gdb $KBUILD_OUTPUT/vmlinux >>> GNU gdb (GDB) 7.3.1-gg2 >>> Copyright (C) 2011 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 "--host=x86_64-linux-gnu >>> --target=arm-linux-android". >>> For bug reporting instructions, please see: >>> <http://www.gnu.org/software/gdb/bugs/>... >>> Reading symbols from /xxx/git_linus/build/dragon_linus_3.17/vmlinux...done. >>> (gdb) target remote /dev/pts/53 >>> Remote debugging using /dev/pts/53 >>> kgdb_breakpoint () >>> at /xxx/git_linus/linux--3.17/kernel/debug/debug_core.c:1050 >>> 1050 arch_kgdb_breakpoint(); >>> (gdb) b sys_sync >>> Breakpoint 1 at 0xc031d450: file >>> /xxx/git_linus/linux--3.17/fs/sync.c, line 103. >>> (gdb) c >>> Continuing. >>> >> >> What a great clarification, Frank. However, I'm having trouble (at >> least) with >> minicom. I've never used it, so I've installed, created the >> configuration file >> with "minicom -s" and changed the "serial port setup" -> "serial >> device" option >> to /dev/ttyS0 > > You will not be connecting minicom to /dev/ttyS0, you will be connecting to > /dev/pts/1. dev/pts/1 is the pty that kdmx reports that it is providing for > the terminal emulator in your example below. The exact pty number may change > when you run kdmx multiple times, or if you terminate and restart your > terminal emulator or gdb. kdmx will report the pty number every time it > changes. You did specify the pty numbers correctly in your example below. > Ok, I thought I needed to put "/dev/ttyS0" on the minicom's "serial port setup" option, and then call minicom with /dev/pts/1 as an argument. I've changed that (I had done it before also), but I'm still in the same place. And yes, I've already noticed the pty changes after using kdmx or restarting the content on the other consoles. I'm always calling minicom with the correct slave pty for the terminal emulator, but yet with no luck. EDIT 2: It seems minicom is working, and so this is past. Also, because we are not dealing with a real connection, it seems the value in "serial port setup" -> "serial device" option is irrelevant. >> >>>> Host window #1 (kdmx): >> >> $ ./kdmx -n -d -p /dev/ttyS0 -b 115200 >> serial port: /dev/ttyS0 >> Initalizing the serial port to 115200 8n1 >> /dev/pts/1 is slave pty for for terminal emulator >> /dev/pts/3 is slave pty for gdb >> >> (now I removed "kgdbwait" from the boot configuration file, to allow the >> target system to boot till the end without needing to send the >> "cont" command >> from GDB, and the I rebooted the target) >> >>>> Host window #2 (minicom): >> >> $ minicom -o -w -p /dev/pts/1 >> Welcome to minicom 2.3 >> >> OPTIONS: I18n >> Compiled on Aug 19 2010, 05:48:57. >> Port /dev/ttyS0 > > Despite minicom reporting "Port /dev/ttyS0", the port should actually > be the /dev/pts/1 that you specified with the -p option. > > My minicom is version 2.5, yours is 2.3. I do not know if that makes > any difference. > Actually, after changing the "Serial port setup" -> "Serial device" option to the correct one ("/dev/pts/1"), minicom main screen changes it accordingly. Regarding versions, probably you already read my first paragraph in this e-mail, so you know I'll try version 2.5. EDIT 3: it seems minicom is (strangely?) working :] >> >> Press CTRL-A Z for help on special keys >> >> >> So, it seems minicom is initialized correctly, however despite seeing the >> cursor of the terminal, if I try to insert commands on it nothing will >> change / happen (I can't even see the commands I'm trying to type appearing >> in the screen). Pressing CTRL+A Z brings me the menu with options, but after > > If minicom is not communicating through kdmx to the target, then you can not > move on to the next step (kgdb) if you are using the /proc/sysrq-trigger > method to enable kgdb. > > You can turn on some kdmx debug options to have it print out the data that > it sends and receives. > > -DtT will show all traffic between kdmx and the terminal emulator. I would > start with this to make sure that minicom and kdmx are communicating. > > -DsS will show all traffic between kdmx and the serial port to the target. > If -DtT showed proper communication, then I would then use this option. > > You can turn on both terminal emulator traffic and serial port traffic at > the same time, but the debug output format then becomes very ugly and > hard to read. I normally just turn on -DsS. (You can also use -DgG to > show all traffic between kdmx and gdb.) > > I will attach examples of using the debug options at the end of this email. 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? My version of your last example: 1. First, typed @ minicom: "echo g >/proc/sysrq-trigger <enter>" 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 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 ty for for terminal emulator /dev/pts/5 is slave pty for gdb s> echo g >/proc/sysrq-trigger 0x0d +$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, 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. EDIT 4: I removed kgdbwait again, and so I have the target OS booted till the end. >> Remote debugging using /dev/pts/3 >> Ignoring packet error, continuing... >> warning: unrecognized item "timeout" in "qSupported" response >> Ignoring packet error, continuing... >> >> >> Many, many thanks. >> João > > < snip > > > Examples of using the kdmx debug options: > > # ---------- example 1 - terminal emulator > # in minicom, typed: echo "test -DtT" > > [1]: ./kdmx -n -d -p/dev/ttyUSB0 -b115200 -DtT > serial port: /dev/ttyUSB0 > Initalizing the serial port to 115200 8n1 > /dev/pts/58 is slave pty for for terminal emulator > /dev/pts/59 is slave pty for gdb > > t> e > t< e > t> c > t< c > t> h > t< h > t> o > t< o > t> > t< > t> " > t< " > t> t > t< t-DtT > t> e > t< e > t> s > t< s > t> t > t< t > t> > t< > t> - > t< - > t> D > t< D > t> t > t< t > t> T > t< T > t> " > t< " > t> 0x0d > > t< 0x0d 0x0a > test -DtT 0x0d 0x0a > % > > > # ---------- example 2 - serial port > # in minicom, typed: echo "test -DsS" > > [1]: ./kdmx -n -d -p/dev/ttyUSB0 -b115200 -DsS > serial port: /dev/ttyUSB0 > Initalizing the serial port to 115200 8n1 > /dev/pts/58 is slave pty for for terminal emulator > /dev/pts/59 is slave pty for gdb > > s> e > s< e > s> c > s< c > s> h > s< h > s> o > s< o > s> > s< > s> " > s< " > s> t > s< t > s> e > s< e > s> s > s< s > s> t > s< t > s> > s< > s> - > s< - > s> D > s< D > s> s > s< s > s> S > s< S > s> " > s< " > s> 0x0d > > s< 0x0d 0x0a > test -DsS 0x0d 0x0a > % > > > # ---------- example 3 - terminal emulator and serial port > # in minicom, typed: echo "test -DtT -DsS" > > [1]: ./kdmx -n -d -p/dev/ttyUSB0 -b115200 -DtT -DsS > serial port: /dev/ttyUSB0 > Initalizing the serial port to 115200 8n1 > /dev/pts/58 is slave pty for for terminal emulator > /dev/pts/59 is slave pty for gdb > > t> e > s> e > s< e > t< e > t> c > s> c > s< c > t< c > t> h > s> h > s< h > t< h > t> o > s> o > s< o > t< o > t> > s> > s< > t< > t> " > s> " > s< " > t< " > t> t > s> t > s< t > t< t > t> e > s> e > s< e > t< e > t> s > s> s > s< s > t< s > t> t > s> t > s< t > t< t > t> > s> > s< > t< > t> - > s> -sudo s< - > t< - > t> D > s> D > s< D > t< D > t> t > s> t > s< t > t< t > t> T > s> T > s< T > t< T > t> > s> > s< > t< > t> - > s> - > s< - > t< - > t> D > s> D > s< D > t< D > t> s > s> s > s< s > t< s > t> S > s> S > s< S > t< S > t> " > s> " > s< " > t< " > t> 0x0d > > s> 0x0d > > s< 0x0d > t< 0x0d > s< 0x0a > > t< 0x0a > > s< t > t< t > s< e > t< e > s< s > t< s > s< t > t< t > s< > t< > s< - > t< - > s< D > t< D > s< t > t< t > s< T > t< T > s< > t< > s< - > t< - > s< D > t< D > s< s > t< s > s< S > t< S > s< 0x0d > t< 0x0d > s< 0x0a > > t< 0x0a > -DtT > s< % > t< % > s< > t< > > > # ---------- example 4 - serial port, connecting gdb to target > # in minicom, typed: echo g >/proc/sysrq-trigger > # then in gdb, typed: target remote /dev/pts/59 > # c > # then in minicom, typed: echo "target running again" > # > # There is some additional output to the console while typing > # 'echo "target running again"' in minicom. That is just a > # coincidence. > # > # The gdb conversation will be different for your target because > # my target is ARM instead of x86. > > [1]: ./kdmx -n -d -p/dev/ttyUSB0 -b115200 -DsS > serial port: /dev/ttyUSB0 > Initalizing the serial port to 115200 8n1 > /dev/pts/58 is slave pty for for terminal emulator > /dev/pts/59 is slave pty for gdb > > s> 0x0d > > s< 0x0d 0x0a > % > s> e > s< e > s> c > s< c > s> h > s< h > s> o > s< o > s> > s< > s> g > s< g > s> > s< > s> > > s< > > s> / > s< / > s> p > s< p > s> r > s< r > s> o > s< o > s> c-DtT > s< c > s> / > s< / > s> s > s< s > s> y > s< y > s> s > s< s > s> r > s< r > s> q > s< q > s> - > s< --DtT > s> t > s< t > s> r > s< r > s> i > s< i > s> g > s< g > s> g > s< g > s> e > s< e > s> r > s< r > s> 0x0d > > s< 0x0d 0x0a > [68806.702614] SysRq : DEBUG 0x0d 0x0a > $T05thread:01;#07 > s> +$qSupported:qRelocInsn+#9a > s< +$#00 > s> +$Hg0#df > s< +$OK#9a > s> +$?#3f > s< +$S05#b8 > s> +$Hc-1#09 > s< +$OK#9a > s> +$qC#b4 > s< +$QC01#f5 > s> +$qAttached#8f > s< +$#00 > s> +$qOffsets#4b > s< +$#00 > s> +$g#67 > s< > +$670000001300006000000000000000000079a2c00479a2c044649ac0070000000000000000000000000000000200000000000000107f05ee8c084fc0446928c000000000000000000000000000000000000000000000000000000000000000000000000000000000#40 > s> +$mc0286944,4#a1 > s< +$ffdeffe7#fd > s> +$qSymbol::#5b > s< +$#00 > s> +$qTStatus#49 > s< +$#00 > s> +$vCont?#49 > s< +$#00 > s> +$Hc0#db > s< +$OK#9a > s> +$c#63 > s< +% > s> e > s< e > s> c > s< c > s> h > s< h > s> o > s< o > s> > s< > s> " > s< " > s> tsudo s< t > s> a > s< a > s> r > s< r > s> g > s< g > s> e > s< e > s> t > s< t > s> > s< > s> r > s< r > s> u > s< u > s> n > s< [68874.464105] random: nonblocking pool is initialized 0x0d 0x0a > n > s> n > s< n > s> i > s< i > s> n > s< n > s> g > s< g > s> > s< > s> a > s< a > s> g > s< g > s> a > s< a > s> i > s< i > s> n > s< n > s> " > s< " > s> 0x0d > > s< 0x0d 0x0a > target running again 0x0d 0x0a > % ------------------------------------------------------------------------------ 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
