[Qemu-devel] qemu on centos

[Qemu-devel] qemu on centos

[Reed Kotler]

We have been seeing various problems running qemu for MIPS target on 
Centos 5.
We are running linux user mode programs.

Qemu segfaults.

We recently tried upgrading to Centos 6 and the problem there is much 
worse, making it basically unusable.

The same programs have no problem when running on Ubuntu.

Is this a known problem?

Any ideas?

TIA.

Reed

Re: [Qemu-devel] [target-mips] qemu on centos

[Andreas Färber]

Hi,

Am 23.12.2011 13:44, schrieb Reed Kotler:
> We have been seeing various problems running qemu for MIPS target on
> Centos 5.
> We are running linux user mode programs.
> 
> Qemu segfaults.
> 
> We recently tried upgrading to Centos 6 and the problem there is much
> worse, making it basically unusable.
> 
> The same programs have no problem when running on Ubuntu.

They likely are using different QEMU versions, and distros may have
different patches applied on top.
Please provide some more info on what version, what ABI (which
executable), what -cpu parameter (if any), etc. you are using. Does a
gdb backtrace indicate any QEMU function or is it from translated code?

For n64 there were some patches in need of testing, review and fixing.
[cc'ing Khansa]

For n32 there's signal handling missing. (openSUSE for one ignores the
build warning and provides it non the less.)

No known issues specific to o32 that I'm aware of, but the two Richards
had patches for some instructions. Shouldn't lead to segfaults though.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [target-mips] qemu on centos

[Stefan Weil]

Am 23.12.2011 23:57, schrieb Stefan Weil:
> Am 23.12.2011 19:05, schrieb Brendan Kirby:
>> Attached are three MIPS binaries that I have seen segfault
>> intermittently on CentOS 6 machines. Just run them with no arguments
>> several times.
>>
>> Brendan
>>
> I tried your binaries with latest QEMU. All three fail here each time
> with SIGSEGV. This is caused by a jump to address 0 (pc = 0).
> Up to now I don't know the reason for this jump.

[snip]

> An older qemu-mipsel from August fails, too.
>
> Regards,
> Stefan Weil

A version from May is better: it also has a jump to address 0,
but handles it correctly:

qemu-mipsel -L /media/vm/tftpboot/mips/malta-le mipsbin/bisort.llc.mips32r2
qemu: unhandled CPU exception 0xc - aborting
pc=0x00000000 HI=0x0000018a LO=0x0000f816 ds 0022 00000000 0
GPR00: r0 00000000 at fffffff8 v0 4081190c v1 00000814
GPR04: a0 0040107c a1 00000001 a2 4080043c a3 004012a0
GPR08: t0 00401344 t1 0ffffffe t2 00000063 t3 00000002
GPR12: t4 40800190 t5 40800238 t6 ffffffff t7 004006a8
GPR16: s0 4083a010 s1 00400660 s2 00000000 s3 00000000
GPR20: s4 00000000 s5 00000000 s6 00000000 s7 00000000
GPR24: t8 00000000 t9 00000000 k0 00000000 k1 00000000
GPR28: gp 00411544 sp 40800418 s8 00000000 ra 00401520
CP0 Status  0x00000000 Cause   0x00000000 EPC    0x00000000
     Config0 0x80000482 Config1 0x9e190c8f LLAddr 0xffffffff
CP1 FCR0 0x00000000  FCR31 0x00000000  SR.FR 0  fp_status 0x00
  f0: w:3f800000 d:400000003f800000 fd:  4.61169e+18 fs:  1.06535e+09 
psu:  1.07374e+09
  f2: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
  f4: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
  f6: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
  f8: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f10: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f12: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f14: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f16: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f18: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f20: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f22: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f24: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f26: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f28: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
f30: w:00000000 d:0000000000000000 fd:            0 fs:            0 
psu:            0
qemu: uncaught target signal 6 (Aborted) - core dumped

Obviously signal handling for SIGSEGV in user code changed.
It now raises a SIGSEGV on the host...

Merry Christmas

Stefan Weil