Citando Frank Rowand <frowand.l...@gmail.com>:

> On 10/10/2014 2:51 AM, joaoandrefe...@sapo.pt wrote:
>> Citando Frank Rowand <frowand.l...@gmail.com>:
>>> On 10/9/2014 10:54 AM, joaoandrefe...@sapo.pt wrote:
>>>> Citando Frank Rowand <frowand.l...@gmail.com>:
>
> < snip >
>
>>>> 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.
>>>
>>
>> One interesting detail is that I ran things in the order you
>> mentioned above ("./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS" and
>> "minicom -o -w -p /dev/pts/1" on the host, and then booting the
>> kernel to be debugged in the target - without PuTTY), and I
>> got the following output @ kdmx:
>>
>> serial port: /dev/ttyS0
>> Initalizing the serial port to 115200 8n1
>> /dev/pts/1 is slave pty for for terminal emulator
>> /dev/pts/2 is slave pty for gdb
>>
>> s< 0x00
>>
>> This "s< 0X00" isn't coming from the target, or am I wrong?
>
> It is coming from the target.  Probably an artifact of the
> driver initializing.  0x00 is NULL, which is usually ignored
> on a serial port.
>
> < snip >
>
>> I think I got it. Now I'll just have to understand what's
>> wrong on the target and change things accordingly.
>
> Reference: kernel source code:
>    Documentation/kernel-parameters.txt
>    Documentation/serial-console.txt
>
>
> On your target kernel boot line, add something like:
>
>    console=ttyS0,115200n8
>
> The serial device name you need to use should be the same
> name that you earlier connected PuTTY to.  I am guessing
> that it is ttyS0.
>
> ***** Read Documentation/serial-console.txt, especially the
> ***** 7 step example at the end, for other details you
> ***** might need, such as setting up getty so you can
> ***** login on the console (from minicom on the host).
>
> -Frank

Hello again, Frank,

I added the "console=ttyS0,115200n8" option you mentioned in the  
target kernel boot line, and then rebooted the target. When CentOS  
finished booting on the target, I started both kdmx ("./kdmx -n -d  
-p/dev/ttyS0 -b115200 -DsS") and minicom ("minicom -o -w -p  
/dev/pts/1") on the host. Then I rebooted the target again, and kdmx  
started receiving input from target (output below). From what I was  
able to see, it seems minicom received the same information (excluding  
the "0x0d" and "0x0a" chars at the end of each line). When the target  
reached the GRUB screen (and after choosing to boot the target  
kernel), kdmx received an error (last line on the output below) and  
exited, which of course made minicom execution fail. Can I consider  
the fact of kdmx and minicom getting input from the target as an  
improvement?

Also, I have a conceptual question for you. Isn't it strange that in  
order to run KGDB I'll have to have 2 ports open at the host side  
(with kdmx), and only one at the target? If I only had one port at  
each end (like I had in the beggining, prior to using kdmx), wouldn't  
that work locally (on the target)? I have both host and target  
physically side by side, so if the information about debugging stood  
on the target, I think that wouldn't be a problem for me. Maybe what  
I'm asking is only a silly question, but I didn't fully comprehend the  
theory sorrounding this, and it is a bit frustrating that it seemed  
that the initial setup was working, since traget hanged on boot, and I  
was able to resume it from GDB.

By the way, thank you for the sources!

./kdmx -n -d -p/dev/ttyS0 -b115200 -DsS
serial port: /dev/ttyS0
Initalizing the serial port to 115200 8n1
/dev/pts/1 is slave pty for for terminal emulator
/dev/pts/2 is slave pty for gdb

s< Stopping certmonger: [  OK  ] 0x0d  0x0d  0x0a
Stopping atd: [  OK  ] 0x0d  0x0d  0x0a
Stopping cups: [  OK  ] 0x0d  0x0d  0x0a
Stopping abrt daemon: [  OK  ] 0x0d  0x0d  0x0a
Shutting down postfix: [  OK  ] 0x0d  0x0d  0x0a
Stopping crond: [  OK  ] 0x0d  0x0d  0x0a
Stopping automount: [  OK  ] 0x0d  0x0d  0x0a
Stopping PC/SC smart card daemon (pcscd): [  OK  ] 0x0d  0x0d  0x0a
Stopping acpi daemon: [  OK  ] 0x0d  0x0d  0x0a
Stopping HAL daemon: [  OK  ] 0x0d  0x0d  0x0a
Shutting down ntpd: [  OK  ] 0x0d  0x0d  0x0a
Stopping block device availability: Deactivating block devices: 0x0d  0x0a
end_request: I/O error, dev fd0, sector 0 0x0d  0x0a
   [UMOUNT]: unmounting vg_centos6-lv_home (dm-2) mounted on /home...  
skipping 0x0d  0x0a
   [SKIP]: unmount of vg_centos6-lv_root (dm-0) mounted on / 0x0d  0x0a
end_request: I/O error, dev fd0, sector 0 0x0d  0x0a
[  OK  ] 0x0d  0x0d  0x0a
Stopping FCoE initiator service:  [  OK  ] 0x0d  0x0d  0x0a
Stopping lldpad: [  OK  ] 0x0d  0x0d  0x0a
Stopping OpenCT smart card terminals:  [  OK  ] 0x0d  0x0d  0x0a
  0x0d  0x0a
Stopping NetworkManager daemon: [  OK  ] 0x0d  0x0d  0x0a
Stopping system message bus: [  OK  ] 0x0d  0x0d  0x0a
Stopping rpcbind: [  OK  ] 0x0d  0x0d  0x0a
Stopping auditd: [  OK  ] 0x0d  0x0d  0x0a
Shutting down system logger: [  OK  ] 0x0d  0x0d  0x0a
ip6tables: Setting chains to policy ACCEPT: filter [  OK  ] 0x0d  0x0d  0x0a
ip6tables: Flushing firewall rules: [  OK  ] 0x0d  0x0d  0x0a
ip6tables: Unloading modules: [  OK  ] 0x0d  0x0d  0x0a
iptables: Setting chains to policy ACCEPT: filter [  OK  ] 0x0d  0x0d  0x0a
iptables: Flushing firewall rules: [  OK  ] 0x0d  0x0d  0x0a
iptables: Unloading modules: [  OK  ] 0x0d  0x0d  0x0a
Disabling ondemand cpu frequency scaling: [  OK  ] 0x0d  0x0d  0x0a
Stopping monitoring for VG vg_centos6:   3 logical volume(s) in volume  
group "vg_centos6" unmonitored 0x0d  0x0a
[  OK  ] 0x0d  0x0d  0x0a
Sending all processes the TERM signal... [  OK  ] 0x0d  0x0d  0x0a
Sending all processes the KILL signal... [  OK  ] 0x0d  0x0d  0x0a
Saving random seed:  [  OK  ] 0x0d  0x0d  0x0a
Syncing hardware clock to system time [  OK  ] 0x0d  0x0d  0x0a
Turning off swap:  [  OK  ] 0x0d  0x0d  0x0a
Turning off quotas:  [  OK  ] 0x0d  0x0d  0x0a
Unmounting file systems:  [  OK  ] 0x0d  0x0d  0x0a
init: Re-executing /sbin/init 0x0d  0x0d  0x0a
Please stand by while rebooting the system... 0x0d  0x0a
Restarting system. 0x0d  0x0a
  0xff read() of serial port returned unexpected errno 6942708

Glad to have your help,
João



------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Reply via email to