From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LTifj-0007DV-3j for qemu-devel@nongnu.org; Sun, 01 Feb 2009 15:12:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LTifi-0007D7-CO for qemu-devel@nongnu.org; Sun, 01 Feb 2009 15:12:02 -0500 Received: from [199.232.76.173] (port=54286 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LTifi-0007D2-31 for qemu-devel@nongnu.org; Sun, 01 Feb 2009 15:12:02 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]:50383) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LTifh-0003Zp-Jo for qemu-devel@nongnu.org; Sun, 01 Feb 2009 15:12:02 -0500 Received: from localhost ([127.0.0.1] ident=stefan) by flocke.weilnetz.de with esmtp (Exim 4.69) (envelope-from ) id 1LTifg-0000XQ-1a for qemu-devel@nongnu.org; Sun, 01 Feb 2009 21:12:00 +0100 Message-ID: <4986020F.4010200@mail.berlios.de> Date: Sun, 01 Feb 2009 21:11:59 +0100 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [BUG] Regression in networking code (SIGSEGV) References: <497790E0.7050905@mail.berlios.de> <20090122073800.GK27675@redhat.com> <497B8171.5040409@mail.berlios.de> <20090124215346.GH19498@hall.aurel32.net> <497CD9C2.4010305@mail.berlios.de> <20090126062919.GD15778@redhat.com> In-Reply-To: <20090126062919.GD15778@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU Developers Gleb Natapov schrieb: > On Sun, Jan 25, 2009 at 10:29:38PM +0100, Stefan Weil wrote: > >> Aurelien Jarno schrieb: >> >>> On Sat, Jan 24, 2009 at 10:00:33PM +0100, Stefan Weil wrote: >>> >>> >>>> Gleb Natapov schrieb: >>>> >>>> >>>>> On Wed, Jan 21, 2009 at 10:17:20PM +0100, Stefan Weil wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> the SIGSEGV crash below can be reproduced with Qemu r6391 and "high" net >>>>>> load. >>>>>> >>>>>> I bootet a mips malta kernel from a debian nfs root. While this worked fine, >>>>>> aptitude update hangs during downloads, nfs root is lost and after some time >>>>>> Qemu gets a SIGSEGV. >>>>>> >>>>>> A similar crash occurs with a different mips machine (ar7) and different >>>>>> network hardware (ar7 emac / cpmac), so it is not restricted to pcnet. >>>>>> This second system does not survive the network boot. >>>>>> >>>>>> Up to now, I could not run tests with non-mips systems. >>>>>> >>>>>> I'm fairly sure that 2 weeks ago networking worked without problems in both >>>>>> cases. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> What is your host CPU? How you run qemu (what is your command line)? >>>>> >>>>> >>>>> >>>> Debian amd64 host. >>>> >>>> mipsel-softmmu/qemu-system-mipsel --kernel vmlinux \ >>>> --append "debug nohz=off root=/dev/nfs rw ip=::::malta-le::dhcp" \ >>>> -M malta --net nic --net user -m 256 >>>> >>>> >>> The fact that your host system is 64-bit and you are using the user >>> networking is interesting. You could try to look at revisions 6272 and >>> 6288, they are probably the cause of your problem. >>> >>> >> Yes, you are right. Reverting r6288 results in stable networking again. >> >> Thank you for this hint. >> >> > I also use amd64 host, but I was not able to reproduce this with other > guests. I'll try mips guest. Can you try to reproduce the problem with > different guest (x86 for instance)? > > > -- > Gleb. > Hi, Up to now, I could not get the crash with i386 guests, but I don't think it depends on the guest because all guests share the same binary code of slirp. It does depend on the kind and on the amount of network data, because it is triggered only by fragmented packets (see stack in my first mail). Please note that you have to compile without optimization in order to see the full stack, because ip_reass is normally inlined by the compiler. Running a qemu-system-mipsel which was compiled for 32 bit hosts results in the same kind of crash (I tested this on my amd64 host), so I don't think it depends on the host. Summary: crash in function ip_reass, can be reproduced with 32- and 64-bit qemu executables running on debian amd64, guest systems big or little endian mips malta or ar7 router (all guests are running newer linux kernels). The regression was caused by change r6288. Stefan