[Qemu-devel] Qemu usermode fork problem !

[Qemu-devel] Qemu usermode fork problem !

[Muhammad Nouman]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

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.

Can any one plz tell me what should i do to debug this new thread??
Help me plzzzzz

Thanks
Nouman

[-- Attachment #2: Type: text/html, Size: 647 bytes --]

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

[Peter Maydell]

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

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

[Muhammad Nouman]

[-- Attachment #1: Type: text/plain, Size: 3040 bytes --]

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.maydell@linaro.org>wrote:

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

[-- Attachment #2: Type: text/html, Size: 3960 bytes --]