Re: [Qemu-devel] Qemu usermode fork problem !

[Muhammad Nouman]

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 <address@hidden> wrote:

On 22 April 2013 13:31, Muhammad Nouman <address@hidden> 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