From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Re: 2.6.28.7 domU: 32-bit emulation seems to be broken
Date: Tue, 17 Mar 2009 09:52:59 -0700
Message-ID: <49BFD56B.1040003@goop.org>
References: <gpe0vg$j67$1@ger.gmane.org>	<gpei6e$gcn$1@ger.gmane.org>	<49BAFC72.4040501@goop.org>	<49BB0184.1020503@goop.org>
	<49BB6F4A.90000@gmail.com>	<49BC2994.6040404@goop.org>
	<49BCF38B.3000507@gmail.com>	<49BD2CCA.6070308@goop.org>
	<49BD3A87.3060403@gmail.com> <49BEB487.3090503@goop.org>
	<49BEB526.7060608@goop.org> <49BED2DE.7060203@gmail.com>
	<49BED46C.2040906@goop.org> <49BFAEFA.80605@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <49BFAEFA.80605@gmail.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: =?ISO-8859-15?Q?Sven_K=F6hler?= <sven.koehler@gmail.com>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

Sven K=F6hler wrote:
> Jeremy Fitzhardinge schrieb:
>  =20
>> Sven K=F6hler wrote:
>>    =20
>>> Jeremy Fitzhardinge schrieb:
>>>      =20
>>>> Jeremy Fitzhardinge wrote:
>>>>        =20
>>>>> Do you have auditing enabled?
>>>>>          =20
>>>> (No)
>>>>        =20
>>> You answered yourself, right?
>>> (yes, CONFIG_AUDIT is disabled)
>>>
>>> Can I supply you with any further information?
>>>      =20
>> I need to find/set up an AMD system to try to repro it I think.  I thi=
nk
>> the problem is actually the return from the syscall, rather than the
>> syscall entry itself.  What happens if you run the program under eithe=
r
>> strace or gdb?
>>    =20
>
> The program just works:
>
> # strace ./a.out
> execve("./a.out", ["./a.out"], [/* 24 vars */]) =3D 0
> [ Process PID=3D8968 runs in 32 bit mode. ]
> uname({sys=3D"Linux", node=3D"xen-to1", ...}) =3D 0
> brk(0)                                  =3D 0x80c3000
> brk(0x80c3cb0)                          =3D 0x80c3cb0
> set_thread_area(0xffa5182c)             =3D 0
> brk(0x80e4cb0)                          =3D 0x80e4cb0
> brk(0x80e5000)                          =3D 0x80e5000
> fstat64(1, {st_mode=3DS_IFCHR|0620, st_rdev=3Dmakedev(136, 0), ...}) =3D=
 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) =3D 0xfffffffff7f51000
> write(1, "Hallo Welt!\n"..., 12Hallo Welt!
> )        =3D 12
> exit_group(0)                           =3D ?
>  =20

OK, that confirms that its sysret32 that's failing.  vdso32=3D0 on the=20
kernel command line should be the workaround until we've got a proper fix=
.

    J