Bug 984545 - Fedora 19 / 3.9.9 / Win7 VM / bridge networking / network IO write hangs
Fedora 19 / 3.9.9 / Win7 VM / bridge networking / network IO write hangs
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-15 09:12 EDT by Iain Lea
Modified: 2013-10-08 12:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-08 12:54:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output (76.41 KB, text/plain)
2013-07-15 09:12 EDT, Iain Lea
no flags Details
lspci -v (10.53 KB, text/plain)
2013-09-04 01:41 EDT, Iain Lea
no flags Details
brctl show (90 bytes, text/plain)
2013-09-04 01:42 EDT, Iain Lea
no flags Details

  None (edit)
Description Iain Lea 2013-07-15 09:12:38 EDT
Created attachment 773743 [details]
dmesg output

Description of problem:

After upgrading from Fedora 18 to Fedora 19 a Windows 7
VM running under KVM can no longer write data back to a
NAS attached CIFS share (file is read ok from NAS server).
After anywhere from 20 to 90% on ca. 1GB sized files the
write does not complete and the photoshop process hangs
with a C/C++ or some such runtime error in the Win7 VM.

The Win7 VM under KVM together with NAS server combo has 
been working rock solid since Jan 2012.

Followed the bridge code problems and fixes for 3.9.9 on
Bugzilla and hoped the repo updates today would have 
fixed the write problems. That has not been the case.

If I downgrade to the F18 kernel 3.6.10 and use the Nvidia
OSS Nouveau driver the problem does not occur. Problem is
then that the Graphic and especially Mouse performance in
Win7 VM is BAD (mouse lags so much working on photoshop
images is no longer productive).

Version-Release number of selected component (if applicable):

kernel-3.9.9-302.fc19.x86_64  (and other 3.9.* kernels as well)

How reproducible:

Photoshop on Win7 VM hangs when writing large files to CIFS
share. VM and KVM setup to use br0 bridge interface.

Steps to Reproduce:
1. [OK] read image file from NAS CIFS share in photoshop on Win7 VM
2. [OK] make a change to image
3. [ERROR] save (write) image file back to NAS CIFS share from photoshop

Actual results:

Write to Network CIFS share hangs, does not complete and Win7 program Photoshop crashes with exception.

Expected results:

Write to Network CIFS share should complete.

Additional info:

Intel i7-2600 / 16GB RAM / Nvidia GT440 / OCZ Vortex 240GB
Intel e1000 GigE LAN adaptor
running Fedora 19 64 bit with latest updates including
3.9.9-302 kernel with the latest various bridge fixes!

KVM Windows7 VM running stable since 2011 with just one
active program Photoshop CS5.5 reading and writing PSD
files from a Gigabit connected NAS disk array.

NAS server is a Synology 1511 running OS 4.2 with 5x3TB 
disks in 1 large RAID5 disk array serving NFS and CIFS.

Win7 VM uses the Virt* network and disk drivers and
bridged networking. Again until the F19 upgrade and
3.9.* kernel everything has worked ok with 0 issues.

$ uname -a
Linux fw1-lan010.FQDN 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ netstat -rn
Kernel IP routing table
Destination     Gateway    Genmask         Flags   MSS Window  irtt Iface         U         0 0          0 ppp0 UH        0 0          0 ppp0   U         0 0          0 br0

$ifconfig br0
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet  netmask  broadcast
        ether f4:6d:04:5c:37:b1  txqueuelen 0  (Ethernet)
        RX packets 648175  bytes 135391587 (129.1 MiB)
        RX errors 0  dropped 280  overruns 0  frame 0
        TX packets 723187  bytes 306133909 (291.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ ifconfig em1
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        ether f4:6d:04:5c:37:b1  txqueuelen 1000  (Ethernet)
        RX packets 711085  bytes 188747003 (180.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 861002  bytes 462888704 (441.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7400000-f7420000  

List of RPMs:




Comment 1 Michele Baldessari 2013-09-03 17:12:52 EDT
Hi Iain,

I'll see if I can reproduce here. Can you give me the output of:
lspci -v
brctl show

Also can you try with a 1500 mtu and see if you can reproduce?
What version of the Windows virtio drivers did you use?

Comment 2 Iain Lea 2013-09-04 01:41:58 EDT
Created attachment 793466 [details]
lspci -v
Comment 3 Iain Lea 2013-09-04 01:42:45 EDT
Created attachment 793467 [details]
brctl show
Comment 4 Iain Lea 2013-09-04 01:43:07 EDT

lspci and brshow ouputare attached above.

Virtio driver version is:


To workaround this problem I selected Intel e1000 driver and VM networking worked again.

Comment 5 Michele Baldessari 2013-09-08 15:36:23 EDT
Hi Iain,

thanks for the info. So it's either virtio (host side), bridge (host side) or the virtio drivers (guest side). Could you test with the the latest virtio
network drivers for win7 : http://alt.fedoraproject.org/pub/alt/virtio-win/latest/

And let me know if the issue persists?

Thanks and regards,
Comment 6 Josh Boyer 2013-09-18 16:41:51 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 7 Josh Boyer 2013-10-08 12:54:50 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Note You need to log in before you can comment on or make changes to this bug.