From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O9J5s-0006hN-6L
	for qemu-devel@nongnu.org; Tue, 04 May 2010 10:27:28 -0400
Received: from [140.186.70.92] (port=46904 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O9J5n-0006fb-Ah
	for qemu-devel@nongnu.org; Tue, 04 May 2010 10:27:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <nchip@afflict.kos.to>) id 1O9J5m-00036k-2L
	for qemu-devel@nongnu.org; Tue, 04 May 2010 10:27:23 -0400
Received: from afflict.kos.to ([92.243.29.197]:33082)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <nchip@afflict.kos.to>) id 1O9J5l-00036Z-Sw
	for qemu-devel@nongnu.org; Tue, 04 May 2010 10:27:22 -0400
Date: Tue, 4 May 2010 17:27:20 +0300
From: Riku Voipio <riku.voipio@iki.fi>
Message-ID: <20100504142720.GA13644@afflict.kos.to>
References: <4BDAA64F.70509@linuxfoundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BDAA64F.70509@linuxfoundation.org>
Subject: [Qemu-devel] Re: QEMU: current user mode breakage
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Martin Mohring <martinmohring@linuxfoundation.org>
Cc: Jan-Simon =?utf-8?Q?M=C3=B6ller?= <jsmoeller@linuxfoundation.org>, qemu-devel@nongnu.org

On Fri, Apr 30, 2010 at 11:43:43AM +0200, Martin Mohring wrote:
> not sure how to handle the situation. But since the commit of the new
> memory allocator for QEMU user mode, my test suites show it is broken.

The "0 sized write" patch still isn't applied upstream. Is that the issue
(eg visible by ldconfig.real not working) for you, or is "everything broken"
even with that patch applied?

Just run ltp tests without any noticable regressions on debian/armel/sid.
No performance slowdown was observerd either.