[Qemu-devel] Networking hangs

[Qemu-devel] Networking hangs

[Christoffer Dall]

Hi.

I am experiencing problems with bridged networking to ARM guests. I have 
experimented with various kernel versions, distributions and host 
machines and I experience the problem in all cases.

When I copy files into the guest using SCP, after an undeterministic 
number of megabytes have been copied, the network crashes. At this point 
not even pings to localhost works inside the guest.

I am using v0.11.0, emulating a versatilepb board with an arm1136-r2 cpu 
and using the following parameter for networking when running the system 
emulator:

-net nic,vlan=0 -net 
tap,vlan=0,ifname=tap0,script=$(QEMUIFUP),downscript=$(QEMUIFDOWN)

QEMUIFUP:
ifconfig tap0 192.168.7.1

QEMUIFDOWN:
ifconfig tap0 down

Any help is greatly appreciated.

Best,
Christoffer Dall

Re: [Qemu-devel] Networking hangs

[Scott Tsai]

On Fri, Nov 20, 2009 at 6:48 AM, Christoffer Dall <cdall@vmware.com> wrote:
> When I copy files into the guest using SCP, after an undeterministic number
> of megabytes have been copied, the network crashes. At this point not even
> pings to localhost works inside the guest.

I cannot reproduce this with v0.11.0 emulating an ARM versatilepb
machine running the dropbear SSH server.

If you would upload your kernel, rootfs and a script to invoke qemu
somewhere I could try and take a look.

Re: [Qemu-devel] Networking hangs

[Christoffer Dall]

Thanks for responding. I have made a tar file available with the scripts 
and images and qemu binary to run my setup: 
http://www.chazy.dk/downloads/qemu-network-test.tar.gz

To produce the error I simply do:
# scp <SOME FILE> root@192.168.7.2:/root/.

The file is approx. 32M large and the network usually crashes around 
17-21 mb of transfer.

The kernel is a stock 2.6.29 with the simple patch to allow versatile 
arm1136 configuration - the patch is included in the tar for reference.


Scott Tsai wrote:
> On Fri, Nov 20, 2009 at 6:48 AM, Christoffer Dall <cdall@vmware.com> wrote:
>> When I copy files into the guest using SCP, after an undeterministic number
>> of megabytes have been copied, the network crashes. At this point not even
>> pings to localhost works inside the guest.
> 
> I cannot reproduce this with v0.11.0 emulating an ARM versatilepb
> machine running the dropbear SSH server.
> 
> If you would upload your kernel, rootfs and a script to invoke qemu
> somewhere I could try and take a look.

Re: [Qemu-devel] Networking hangs

[Aurelien Jarno]

On Thu, Nov 19, 2009 at 05:48:02PM -0500, Christoffer Dall wrote:
> Hi.
>
> I am experiencing problems with bridged networking to ARM guests. I have  
> experimented with various kernel versions, distributions and host  
> machines and I experience the problem in all cases.
>
> When I copy files into the guest using SCP, after an undeterministic  
> number of megabytes have been copied, the network crashes. At this point  
> not even pings to localhost works inside the guest.
>
> I am using v0.11.0, emulating a versatilepb board with an arm1136-r2 cpu  

Have you tried to use the stable-0.11 branch (that will become 0.11.1 at
some point) instead? It has some ARM and network related fixes.

See http://git.savannah.gnu.org/cgit/qemu.git/log/?h=stable-0.11

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Networking hangs

[Scott Tsai]

On Sat, Nov 21, 2009 at 7:29 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Thu, Nov 19, 2009 at 05:48:02PM -0500, Christoffer Dall wrote:
>> Hi.
>>
>> I am experiencing problems with bridged networking to ARM guests. I have
>> experimented with various kernel versions, distributions and host
>> machines and I experience the problem in all cases.
>>
>> When I copy files into the guest using SCP, after an undeterministic
>> number of megabytes have been copied, the network crashes. At this point
>> not even pings to localhost works inside the guest.
>>
>> I am using v0.11.0, emulating a versatilepb board with an arm1136-r2 cpu
>
> Have you tried to use the stable-0.11 branch (that will become 0.11.1 at
> some point) instead? It has some ARM and network related fixes.

Using the files that Christoffer uploaded, I can reproduce this bug
even on stable-0.11.
(i.e. using scp to copy a large file seems to "hang" the network stack
in the guest to the point that even "ping 127.0.0.1" fails)

The interesting part about this bug is that Christoffer patched the
Linux kernel to allow using an ARMv6 CPU on the versatilepb board.
I've verified that by changing the emulated cpu from arm1136-r2 to
arm926 and building a kernel for the arm926 this bug no longer
happens.

I'm not familiar enough with the ARM architecture to explain why the
versatilepb board would have such "reliability problems" with
arm1136-r2 CPU right away.
I was about to try emulating a arm1136-r2 CPU on a realview board.

Re: [Qemu-devel] Networking hangs

[Christoffer Dall]

Hi there.

I tried to verify if the bug existed with Realview, but I just can't get 
the guest to mount an sd-card, which I created with qemu-img and copied 
a roots onto there and the guest kernel cannot be configured with 
PCI/SCSI support for the ext2 image.

Do you have any ideas on how to proceed with either the realview stuff 
to see if that's the problem or with the networking issue?

Thanks!

Best,
Christoffer

Scott Tsai wrote:
> On Sat, Nov 21, 2009 at 7:29 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> On Thu, Nov 19, 2009 at 05:48:02PM -0500, Christoffer Dall wrote:
>>> Hi.
>>>
>>> I am experiencing problems with bridged networking to ARM guests. I have
>>> experimented with various kernel versions, distributions and host
>>> machines and I experience the problem in all cases.
>>>
>>> When I copy files into the guest using SCP, after an undeterministic
>>> number of megabytes have been copied, the network crashes. At this point
>>> not even pings to localhost works inside the guest.
>>>
>>> I am using v0.11.0, emulating a versatilepb board with an arm1136-r2 cpu
>> Have you tried to use the stable-0.11 branch (that will become 0.11.1 at
>> some point) instead? It has some ARM and network related fixes.
> 
> Using the files that Christoffer uploaded, I can reproduce this bug
> even on stable-0.11.
> (i.e. using scp to copy a large file seems to "hang" the network stack
> in the guest to the point that even "ping 127.0.0.1" fails)
> 
> The interesting part about this bug is that Christoffer patched the
> Linux kernel to allow using an ARMv6 CPU on the versatilepb board.
> I've verified that by changing the emulated cpu from arm1136-r2 to
> arm926 and building a kernel for the arm926 this bug no longer
> happens.
> 
> I'm not familiar enough with the ARM architecture to explain why the
> versatilepb board would have such "reliability problems" with
> arm1136-r2 CPU right away.
> I was about to try emulating a arm1136-r2 CPU on a realview board.

Re: [Qemu-devel] Networking hangs

[Scott Tsai]

On Fri, Dec 4, 2009 at 8:55 AM, Christoffer Dall <cdall@vmware.com> wrote:
> I tried to verify if the bug existed with Realview, but I just can't get the
> guest to mount an sd-card, which I created with qemu-img and copied a roots
> onto there and the guest kernel cannot be configured with PCI/SCSI support
> for the ext2 image.
>
> Do you have any ideas on how to proceed with either the realview stuff to
> see if that's the problem or with the networking issue?

I did a quick linux kernel hack to support the versatile_pci
compatible PCI controller for realview-eb boards.
Using the new stable-0.12 branch of qemu and the new 'realview-eb'
machine type, scp'ing large files into qemu no longer hangs the
network on ARMv6 CPUs.

kernel patch (trivial but ugly):
http://gitorious.org/scottt/linux-arm/commits/realview-eb-qemu
realview-eb-qemu branch

kernel config:
http://scottt.tw/bug/qemu-network-hang/realview-eb-qemu_defconfig

prebuilt kernel zImage:
http://scottt.tw/bug/qemu-network-hang/zImage-2.6.32-realview-eb-qemu-v6

script to launch qemu:
http://scottt.tw/bug/qemu-network-hang/launch-qemu

I used the same rootfs.ext2 image that you uploaded.
Sorry for the late reply, other priorities intruded.