Messages in this thread |  | | | Date | Wed, 17 Sep 2008 16:20:31 +0200 | | From | Denis Joseph Barrow <> | | Subject | Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued |
| |
Hi Jason, The problem I believe is very reproducable. I'm doing nothing special with kgdb just using it to help me with 3g modem driver development & my driver wasn't loaded when the problem occured. I have the following command in my /boot/grub/menu.lst kernel parameter to enable gdb. kgdboc=/dev/ttyS0,115200 maxcpus=1
And when I do the steps mentioned when in a console I get a message waiting for gdb to attach I'm familiar with kgdb, have been using it for years & know enough to be sure this is undesired behaviour.
Jason Wessel wrote: > Denis Joseph Barrow wrote: >> Hi ladies/gentlemen, >> The kernel I'm running gdb with is 2.6.27-rc4 >> The false sigtrap is occuring in ia32_sysenter_target in arch/x86/kernel/entry_32.S:303 >> when gdb is stepped from the user process as described below >> >> > > Your example does not indicate how or why you setup kgdb. kgdb can be > compiled into the kernel, but it should not have any effect what so ever > unless it is configured for use because it will not register to receive > any of the breakpoint or single stepping traps. > > Perhaps there is more to the description of your problem? > > Jason. > >> To reproduce >> compile kernel with kgdb support >> compile my randsleep program attached using the .mk script >> as root >> attach randsleep to an idle serial port e.g. /dev/ttyS0 by typing >> randsleep /dev/ttyS0 >> from another bash shell type >> ps -aux | grep randsleep >> >> gdb ./randsleep >> attach <pid of randsleep> >> >> You should get messages from gdb like >> Attaching to program: /home/djbarrow/devel2/randsleep/randsleep, process 6397 >> Reading symbols from /lib/tls/i686/cmov/libc.so.6...done. >> Loaded symbols for /lib/tls/i686/cmov/libc.so.6 >> Reading symbols from /lib/ld-linux.so.2...done. >> Loaded symbols for /lib/ld-linux.so.2 >> 0xb7fda430 in __kernel_vsyscall () >> >> Now type step. >> >> The machine is now hung until gdb attaches remotely. >> >> >>
-- best regards, D.J. Barrow
|  |