[Top][All Lists]
[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, 25 Jan 2009 22:29:38 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.19 (X11/20090103) |
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.
Stefan
>
>> The target system is Debian mips.
>>
>> Regards
>> Stefan
>>
>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> [Switching to Thread 0x7f3be89386e0 (LWP 14845)]
>>>> 0x00000000004d1a6f in ip_reass (ip=0xfe96e0, fp=0x1109050) at
>>>> ~/src/qemu/trunk/slirp/ip_input.c:408
>>>> 408 ip->ip_len = next;
>>>> (gdb) i s
>>>> #0 0x00000000004d1a6f in ip_reass (ip=0xfe96e0, fp=0x1109050) at
>>>> ~/src/qemu/trunk/slirp/ip_input.c:408
>>>> #1 0x00000000004d15ad in ip_input (m=0x110e010) at
>>>> ~/src/qemu/trunk/slirp/ip_input.c:228
>>>> #2 0x00000000004b3d25 in slirp_input (pkt=0x12fcbd0 "RT", pkt_len=1294)
>>>> at ~/src/qemu/trunk/slirp/slirp.c:679
>>>> #3 0x000000000049a07d in qemu_send_packet (vc1=0x10ff440, buf=0x12fcbd0
>>>> "RT", size=1294) at ~/src/qemu/trunk/net.c:399
>>>> #4 0x000000000042ea6a in pcnet_transmit (s=0x12fc810) at
>>>> ~/src/qemu/trunk/hw/pcnet.c:1300
>>>> #5 0x000000000042ebd8 in pcnet_poll_timer (opaque=<value optimized
>>>> out>) at ~/src/qemu/trunk/hw/pcnet.c:1363
>>>> #6 0x000000000042f270 in pcnet_ioport_writew (opaque=0x7f3be72a79e0,
>>>> addr=17884784, val=16684768)
>>>> at ~/src/qemu/trunk/hw/pcnet.c:1645
>>>> #7 0x0000000000405eb8 in ioport_write (index=1, address=4146, data=0)
>>>> at ~/src/qemu/trunk/vl.c:302
>>>> #8 0x00000000004062b5 in cpu_outw (env=0x0, addr=4146, val=0) at
>>>> ~/src/qemu/trunk/vl.c:432
>>>> #9 0x00000000420ae755 in ?? ()
>>>> #10 0x0000000000000000 in ?? ()
>>>> (gdb) up
>>>> #1 0x00000000004d15ad in ip_input (m=0x110e010) at
>>>> ~/src/qemu/trunk/slirp/ip_input.c:228
>>>> 228 ip = ip_reass(ip, fp);
>>>> (gdb) p ip
>>>> $1 = (struct ip *) 0x110e060
>>>> (gdb) do
>>>> #0 0x00000000004d1a6f in ip_reass (ip=0xfe96e0, fp=0x1109050) at
>>>> ~/src/qemu/trunk/slirp/ip_input.c:408
>>>> 408 ip->ip_len = next;
>>>> (gdb) p *ip
>>>> Cannot access memory at address 0xfe96e0
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Gleb.
>>>
>>>
>>
>>
>
>