qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [BUG] Regression in networking code (SIGSEGV)


From: Stefan Weil
Subject: Re: [Qemu-devel] [BUG] Regression in networking code (SIGSEGV)
Date: Sun, 01 Feb 2009 21:11:59 +0100
User-agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]