Many Thanks for the reply. I am getting the following error when another processes is created by fork system call.Here 743 is the process id of the new process created .*
**SigNo=0init/743: potentially unexpected fatal signal 0. <4> <4>Cpu 0 <4>$ 0 : 0000000000000000 0000000000000000 ffffffffffff9018 00000000000000a8 <4>$ 4 : 00000000000000a8 0000000000000000 00000001200aca40 0000000000000000 <4>$ 8 : 0000000000000000 0000000000000005 8101010101010100 000000000000002f <4>$12 : 0000000000000000 0000000000000020 ffffffff841dd468 000000012a712000 <4>$16 : 0000000120076280 0000000000000000 0000000120076168 000000000000008d <4>$20 : ffffffff848dc658 0000000000000000 0000000000000000 0000000000000000 <4>$24 : 0000000000000006 000000012004f320 <4>$28 : 00000001200aca40 000000ffffba2d50 000000ffffba2d50 0000000120011410 <4>Hi : 0000000000000042 <4>Lo : 6666666666666677 <4>epc : 000000012004f348 0x12004f348 <4> Not tainted <4>ra : 0000000120011410 0x120011410 <4>Status: 04008df3 KX SX UX USER EXL IE <4>Cause : 80800008 <4>BadVA : 00000000000000a8 <4>PrId : 000d0408 (Cavium Octeon+) *After seeing the Qemu log , i see the load exception at this virtual address *00000000000000a8* at the following point 0x000000012004f34c: ld v0,0(v1) When i try to find out the code behind that above exception address *0x000000012004f34c *in the vmlinux file using objdump, i don't get anything. After seeing this detail, can u plz elaborate to me more about what should i do next? A little help would highly be appreciated. Thanks *Nouman * On Mon, Apr 22, 2013 at 5:53 PM, Peter Maydell <peter.mayd...@linaro.org>wrote: > On 22 April 2013 13:31, Muhammad Nouman <nouman...@gmail.com> wrote: > > Hi ! I am trying to emulate cavium octeon's mips64 linux kernel on > Qemu.When > > the fork system call is generated from usermode (i.e from init code), > after > > creating a new thread, the kernel gets a fatal signal from the new thread > > and then the new thread never runs. > > > > I have tried to debug this new thread but the gdb is always showing a > single > > thread when the "info threads" command is run.It is not showing the other > > threads. > > When you connect a gdb to QEMU's system emulation, you should not > expect to be able to see different user mode processes or threads: > you just see the state of the physical CPU (which may be running > kernel code or user code, depending). This is similar to the view > you get if you connect a debugger to a JTAG port on real hardware. > > Note that "the kernel gets a fatal signal from the new thread" is > backwards -- the kernel sends signals to threads, not the other > way around. You should probably try to identify why the kernel > thinks it should be sending a signal to this new thread (probably > provoked by a hardware exception) and work backwards to figure > out why the hardware exception has occurred. > > PS: the fork system call creates new processes, not new threads > (the latter is done via clone). > > -- PMM >
