Jay Lan wrote: > Jason Wessel wrote: > >> Jay Lan wrote: >> >>>> >>>> >>> Hi Jason, >>> >>> Please disregard the above comment. The kernel was hung in running init, >>> not during booting the kernel. I need to find what caused this problem >>> in this particular system setup. >>> >>> Now, i put in kgdbwait in the boot command line and the kernel stopped >>> and wait for gdb to connect. The documentation says to use the following >>> for connecting a terminal server: >>> (gdb) target remote udp:192.168.2.2:6443 >>> >>> I replaced the ip with the ip of my terminal server, and the port number >>> with the port number when i connect to the console of the target system. >>> >>> Still no connection! Does the system i run gdb on have to be on the same >>> subnet as the target system? Hmm, i will find another system to test >>> tomorrow... >>> >>> >>> >> Not real sure where you got the target remote "udp" but most if not all >> terminal servers use tcp. What ever address and port you connect to >> with your terminal program is the same as what you would use for the gdb >> target remote command. >> > > Hi Jason, it is from around line 406 of Documentation/DocBook/kgdb.tmpl. > > Example (kgdb to a terminal server): > </para> > <programlisting> > % gdb ./vmlinux > (gdb) target remote udp:192.168.2.2:6443 > </programlisting> > <para> > >
Well clearly that is documentation defect. I'll fix it. > Attached is a patch that remove "udp:" from the example. > > However, after removing "udp:" my connection failed in a different > way: > (gdb) target remote 128.162.244.107:7003 > Remote debugging using 128.162.244.107:7003 > warning: unrecognized item "qSupported" in "qSupported" response > Malformed response to offset query, qOffsets > (gdb) > > You do have to make sure you issued the sysrq-g before you connect. To debug such issues you need to also execute the following command prior to issuing the "target remote ...". set debug remote 1 > Has anyone seen this problem before? The kernel was 2.6.26-rc2 and > kgdb source was from kgdb-next about 3 weeks ago. > > I have only seen this sort of behavior if the kernel is not in "kgdb mode" when you connect. > I used kgdboc at the boot line. When i tried to use kgdb8250, as > suggested by xianfeng, the boot stopped at loading initrd. Any extra > module i need to provide mkinitrd? I had CONFIG_KGDB_8250=y. (BTW, > thanks xianfeng, for your example!) > I am not aware of any particular case where the 8250_kgdb module is breaking down. If you build it into the kernel as a built-in you should be able to specify it on the boot line. Of course if you use the kgdb8250 driver it requires a dedicated serial port. Jason. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
