FS#37975 - MacVTap + qemu = hang/lock up

Attached to Project: Arch Linux
Opened by Christoph Haag (haagch) - Sunday, 01 December 2013, 21:56 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Friday, 07 February 2014, 01:21 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Happens with both 3.12 from core and 3.13-rc2.

Reproducing: as described in http://virt.kernelnewbies.org/MacVTap

# ip link add link eth0 name macvtap0 type macvtap
# ip link set macvtap0 address 1a:46:0b:ca:bc:7b up
# chmod a+rw /dev/tap*
$ qemu-system-x86_64 -hda /some/image -net nic,model=virtio,addr=1a:46:0b:ca:bc:7b -net tap,fd=3 3<>/dev/tap*
(assuming there's only one device named /dev/tap* after creating macvtap)


(more or less) upstream link: https://bugzilla.redhat.com/show_bug.cgi?id=1025770 (At least I believe I have the same issue, dmesg looks similar)

The reason I decided to post this here is because #15 said "it's stated that the F20 kernel does not have this bug." so there might be some kernel configuration or patch that can solve this.
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Friday, 07 February 2014, 01:21 GMT
Reason for closing:  Fixed
Comment by Allan McRae (Allan) - Thursday, 02 January 2014, 05:15 GMT
Submitter notes this was fixed in Fedora's 3.12.5. Is this fixed in Arch too?
Comment by Christoph Haag (haagch) - Saturday, 25 January 2014, 21:03 GMT
Oh, I forgot to test. Now I had some time.

I'm using mainline 3.13.

I tried it with libvirt, the archlinux install image and one macvtap "bridge" device.

It worked fine.

So I think it is fixed.

Loading...