Citando Frank Rowand <frowand.l...@gmail.com>: > 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 >
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. 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. 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": serial port: /dev/ttyS0 Initalizing the serial port to 115200 8n1 /dev/pts/2 is slave pty for for terminal emulator /dev/pts/3 is slave pty for gdb 1.2 - Then, ran minicom with "minicom -o -w -p /dev/pts/2" 1.3 - After that, ran GDB and than "set remotebaud 115200" 1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>" t> echo g >/proc/sysrq-trigger 0x0d [also, on the target console (PuTTY)]: echo g>/proc/sysrq-trigger 2 - Then, in GDB: "target remote /dev/pts/3" Remote debugging using /dev/pts/3 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 [also, on the target console, a lot of characters] 3 - Again in minicom: "echo "target running again" <enter>" echo "target running again" 0x0d [also, on the target console, after the characters from point 2]: echo "target running again" Conclusion: So, if I'm not wrong, it seems to work till a certain point, where after GDB displayed "Remote debugging using /dev/pts/3" it does display some errors and then it times out. However, it does echo what is typed in minicom, both in the target PuTTY and on kdmx. But it should be echoing twice in kdmx, isn't it? This is rather strange, and I didn't totally understood if my minicom is running properly, because I can't see neither what I type there (only in kdmx, with the debugging options enabled) nor any output, although this last case could not be minicom's "fault", of course (it can be the target). Thank you so much, again! João ------------------------------------------------------------------------------ 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
