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. > 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. > > 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 This shows PuTTY capturing console output that needs to go to kdmx. > > 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] Those characters should be the target kernel responding to the requests from gdb. "the target console" is PuTTY, running on the host? > > 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
