On 10/9/2014 10:54 AM, joaoandrefe...@sapo.pt wrote: > Citando Frank Rowand <frowand.l...@gmail.com>: > >> 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. > > I'm running PuTTY on the target system, i. e., on the other side of the > host's serial cable. Regarding your scheme, in a previous message: > > ---------------------- HOST -------------------------------------- > --- TARGET --- > > terminal <----> /dev/pty/29 <----> +------+ > emulator | | > | kdmx | <----> serial port <== > cable ==> target console > gdb <---------> /dev/pty/53 <----> | | /dev/ttyUSB0 > +------+ > > I'm running PuTTY on the TARGET (scheme), as the "target console". > Maybe this is not what is supposed to happen, but it was the idea I
Ah, that is yet a different picture than I was understanding. That is wrong and will not work. "target console" on the target is the serial device. The kernel on the target should be printing the boot messages to this device, and at the end of boot either a shell show be attached to this device or a login prompt to enter a shell should appear on this device. You probably select the console device by describing it on the kernel boot line (the same place where you put "kgdbwait"). When the target console is set to the serial device, you will see the console traffic on minicom on the host. Be sure to start kdmx and minicom before booting so you can see the boot messages. ********************************************************** What is in your current kernel boot line? ********************************************************** > got from your previous email. If it isn't PuTTY, what should be? A > normal Linux terminal? Minicom? By the way, prior to that email of > yours, I had the target system simply running the OS "normally", > idle, without anything "special" running to acknowledge the serial > connection (and even before that I had the kgdbwait option set, so > the kernel stopped booting and expected a connection from GDB). So PuTTY is intercepting all of the traffic from the host. This traffic needs to go into the target kernel. If the target console is set to the serial device then this would happen. > >> >>> 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. >> > > I've changed the option in step 1.1. Now I have: > > 1.1 - "./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS" > > serial port: /dev/ttyS0 > Initalizing the serial port to 115200 8n1 > /dev/pts/3 is slave pty for for terminal emulator > /dev/pts/4 is slave pty for gdb > > 1.2 - "minicom -o -w -p /dev/pts/3" > > 1.3 - @ GDB: "set remotebaud 115200" > > 1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>"1.1 - "./kdmx -n > -d -p/dev/ttyS0 -b115200 -DsS" > > serial port: /dev/ttyS0 > Initalizing the serial port to 115200 8n1 > /dev/pts/3 is slave pty for for terminal emulator > /dev/pts/4 is slave pty for gdb > > 1.2 - "minicom -o -w -p /dev/pts/3" > > 1.3 - @ GDB: "set remotebaud 115200" > > 1.4 - Typed @ minicom: "echo g >/proc/sysrq-trigger <enter>" > > @ kdmx: s> echo g >/proc/sysrq-trigger 0x0d > @ PuTTY (on target system): echo g>/proc/sysrq-trigger You need to see the message on the target console that says it is waiting for kgdb before typing the gdb target remote command. In this case, the waiting for kgdb message does not appear because the target kernel never got the "echo g >/proc/sysrq-trigger 0x0d" command, since PuTTY instead got it. If the target console was properly set to the serial port and PuTTY was not running on the target, then the target kernel would write the waiting for kgdb message to the target serial port, then it would come through kgdb to the terminal emulator, and you would see it in minicom. < snip > < the info that was below was helpful in confirming stuff, thanks > -Frank ------------------------------------------------------------------------------ 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
