Bug 799155 - virtio + vhost_new fail with non-kvm guest
virtio + vhost_new fail with non-kvm guest
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
: 799185 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-01 17:02 EST by Arnold Wang
Modified: 2013-02-11 16:58 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-11 16:58:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
rpm build output. (1.72 MB, text/x-log)
2012-03-02 13:32 EST, Arnold Wang
no flags Details

  None (edit)
Description Arnold Wang 2012-03-01 17:02:54 EST
Description of problem:
When I tried to start the Windows 7 guest machine when I set its NIC model to "virtio", I receive the following error message:
qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: vhost-net support is not compiled in
qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: vhost-net requested but could not be initialized
qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: Device 'tap' could not be initialized
The relevant command generated by virtual machine manager 0.9.1 is 
"....
-netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:7c:d2,bus=pci.0,addr=0x3
...."  
However, from what I googled, it appears to me vhost-net should be supported by Fedora 17. In fact, even "lsmod" shows the following:
[awang@mars ~]$ lsmod | grep vhost
vhost_net              33675  0 
macvtap                18183  1 vhost_net
tun                    22768  4 vhost_net

Version-Release number of selected component (if applicable):
[awang@mars ~]$ rpm -qa kernel
kernel-3.2.5-3.fc16.x86_64
[awang@mars ~]$ rpm -qa | grep virt
python-virtinst-0.600.1-1.fc16.noarch
libvirt-python-0.9.6-4.fc16.x86_64
virt-manager-common-0.9.1-2.fc16.noarch
python-virtkey-0.50-9.fc15.x86_64
virt-manager-0.9.1-2.fc16.noarch
libvirt-0.9.6-4.fc16.x86_64
libvirt-client-0.9.6-4.fc16.x86_64


How reproducible:
Create a guest machine, set the NIC model to "virtio" and start it.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
The guest machine won't run.

Expected results:
The guest machine starts.

Additional info:
The complete Windows 7 guest machine configuration is attached.
Comment 1 Laine Stump 2012-03-01 19:14:31 EST
libvirt will only add vhost options to the qemu commandline if two conditions are both true:

1) the vhost-net module is loaded (detected by presence of /dev/vhost-net

2) the output of "qemu-kvm -help" contains the string ",vhost=", indicating that qemu supports this.

It appears there has been a two tiered failure of qemu-kvm in this case:

1) The Fedora build of qemu-kvm was configured to exclude vhost-net support, and

2) When qemu-kvm is built without vhost-net support, it fails to remove those parts of the help text.

I'm moving this bug to the qemu package. The Fedora build of qemu should of course have vhost-net enabled. Beyond that, qemu upstream should be patched to not include mention of vhost-net options if vhost-net support is not built into the binary.
Comment 2 Arnold Wang 2012-03-01 23:39:39 EST
Thanks for the quick response. If I didn't misunderstand you, you're saying vhost-net is not enabled by default Fedora qemu-kvm package. However, when I downloaded the qemu source package, I noticed it states in the SPEC file that:
* Mon Jan 30 2012 Justin M. Forbes <jforbes@redhat.com> - 2:0.15.1-4
- Add vhost-net to kvm.modules
- Fix USB passthrough assert on packet completion (#769625)
I verified that I have that version installed. 
[awang@mars rules.d]$ rpm -q qemu-kvm
qemu-kvm-0.15.1-4.fc16.x86_64
I don't know what's the other way to verify whether it is actually loaded. All other indicators seems showing it's loaded. 
[awang@mars rules.d]$ ls -l /dev/vhost-net 
crw-------. 1 root root 10, 58 Mar  1 19:16 /dev/vhost-net
[awang@mars rules.d]$ qemu-system-x86_64 --help | grep vhost
-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]
                use vhost=on to enable experimental in kernel accelerator
                use vhostforce=on to force vhost on for non-MSIX virtio guests
                use 'vhostfd=h' to connect to an already opened vhost net device
[awang@mars rules.d]$ lsmod | grep vhost
vhost_net              33675  0 
macvtap                18183  1 vhost_net
tun                    22768  2 vhost_net

Any way, I will wait for the response from the qemu group.
Thanks.
Comment 3 Laine Stump 2012-03-02 03:17:50 EST
This message:

> qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25:
> vhost-net support is not compiled in

is printed by qemu-kvm, not by libvirt, and is present in the compiled binary only if qemu was built with CONFIG_VHOST_NET not #defined. So there are two options: 1) you have a locally built qemu-kvm on your system that was built with vhost-net support configured out, or 2) the F17 build of qemu-kvm has vhost-net support configured out.
Comment 4 Arnold Wang 2012-03-02 13:31:56 EST
I recompiled remu packages with vhost-net enabled, at least I thought so, and I'm still seeing the same error messages. 
I have the build log attached.
I'm little bit confused now. Which component need vhost-net support enabled, Kernel, libvirt or qemu? How can I verify whether the vhost-net is "enabled" in those modules? 
As far as I can tell, Kernel module is loaded.  
[awang@mars ~]$ lsmod | grep vhost
vhost_net              33675  0 
macvtap                18183  1 vhost_net
tun                    22768  2 vhost_net
Since The virtual machine manager GUI generated the proper qemu command, I assume libvirt shouldn't be blamed neither.
Comment 5 Arnold Wang 2012-03-02 13:32:50 EST
Created attachment 567127 [details]
rpm build output.
Comment 6 Laine Stump 2012-03-02 15:22:02 EST
The only checks in libvirt are at runtime, as given in Comment 1. The message you are seeing only exists in the qemu-kvm binary, and only exists if it was built with CONFIG_VHOST_NET *not* defined (see Comment 3). The kernel module is a part of the kernel, not a part of qemu or of libvirt.

I'm not sure how/why it could be that rpmbuild is showing you that vhost-net support is enabled for the build, but in the binary it actually isn't, but that appears to be what is happening (look for CONFIG_VHOST_NET in config.h of the build directory).

BTW, why is this BZ filed against F17, but the rpm has fc16 (as do the build logs). The qemu build for F17 is currently using qemu-1.0, not qemu-.15.
Comment 7 Arnold Wang 2012-03-05 01:16:07 EST
The OS is F16. I lost track to the version numbers. :-)
Comment 8 Arnold Wang 2012-03-06 19:16:48 EST
*** Bug 799185 has been marked as a duplicate of this bug. ***
Comment 9 Justin M. Forbes 2012-03-07 12:11:31 EST
From the koji build logs for F17 and F16 we see:

vhost-net support yes

We then proceed to actually build hw/vhost_net.c and don't see any errors there.  The help is accurate here, and qemu-kvm should support vhost_net
Comment 10 Laine Stump 2012-03-07 15:56:40 EST
Arnold,

Can you please tell us the build of qemu-kvm you are using ("rpm -qa qemu-kvm")? Also, did you get the binary from the Fedora repos, or did you build it yourself?
Comment 11 Arnold Wang 2012-03-07 18:59:56 EST
The qemu version is 
[awang@mars ~]$ rpm -q qemu-kvm
qemu-kvm-0.15.1-4.fc16.x86_64
When I first reported the problem, I was using the original Fedora binary. After I submitted the bug, I was told vhost-net is not enabled in the Fedora default build. Since I don't know other way for me to verify, I download the source RPM, add "--enable-vhost-net" to the configure option and rebuild the binary. I have the build output uploaded in this thread. 
Since my own binary didn't make any difference, I'm ready to go back the original one if it helps you to trouble shooting.
Thanks.
Comment 12 Eric Paris 2012-03-08 09:26:30 EST
Interesting note, I just realized that my F17 hypervisor does not make KVM available.  Only QEMU.  The kvm-qemu binary is installed on the box.  The kvm kernel module is loaded on the box.  But virt-manager says "Warning: KVM is not available.  This may mean the KVM package is not installed, or the KVM kernel modules are not loaded.  Your virtual machines may perform poorly."

This means that the error message is coming from /usr/bin/qemu-system-x86_64

The actual command it used was: /usr/bin/qemu-system-x86_64 -S -M pc-0.15 -no-kvm -m 4096 -smp 3,sockets=3,cores=1,threads=1 -name Windows7 -uuid 584066b9-55a1-cd2a-382e-1a2535c70918 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/Windows7.img,if=none,id=drive-scsi0-0-0,format=raw,cache=none -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -drive file=/var/lib/libvirt/images/virtio-win-0.1-22.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/Win7-iso.img,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:76:db:8b,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

Which fails if run from the command line with (I assume not surprisingly):
char device redirected to /dev/pts/1
qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: TUNGETIFF ioctl() failed: Bad file descriptor
TUNSETOFFLOAD ioctl() failed: Bad file descriptor
qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: vhost-net support is not compiled in
qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: vhost-net requested but could not be initialized
qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: Device 'tap' could not be initialized


I believe right now my main goal is to figure out why virt-manager doesn't think KVM is an option on that box.
Comment 13 Daniel Berrange 2012-03-08 09:34:28 EST
> I believe right now my main goal is to figure out why virt-manager doesn't
> think KVM is an option on that box.

Try running the 'virt-host-validate' command as root. It will point out a few  obvious problems it knows about.
Comment 14 Eric Paris 2012-03-08 09:51:52 EST
# virt-host-validate
  QEMU: Checking for hardware virtualization                                 : PASS
  QEMU: Checking for device /dev/kvm                                         : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization)
  QEMU: Checking for device /dev/vhost-net                                   : PASS
  QEMU: Checking for device /dev/net/tun                                     : PASS
   LXC: Checking for Linux >= 2.6.26                                         : PASS

Virt was disabled in BIOS.  When I enabled virt in BIOS I was able to use KVM.  With KVM the virtio nic is working.

This bug appears specific to a virtio nic and non-kvm qemu.
Comment 15 Laine Stump 2012-03-08 11:47:28 EST
Okay, this is starting to make sense. The first layer of failure is that the system in question doesn't have KVM support enabled somehow (in eparis' case, it was due to being disabled in the BIOS, in Arnold's case, it's because his CPU doesn't support KVM). The second layer of failure is that when that happens, qemu-system-x86_64 (or qemu-system-i686 or whatever it's called on 32 bit systems) is run instead of qemu-kvm, and qemu-system-x86_64 has for some reason been configured with vhost support compiled out. The 3rd layer is that even though vhost support has been configure out of qemu-system-x86_64, it still shows up in the help output, so libvirt believes it's available and builds a commandline accordingly.

I don't think there's a reason that qemu-system-X needs to have vhost support disabled, so one solution would be to enable that in the build. If there *is* some reason it needs to be disable in qemu-system-X, then the -help text should be altered accordingly so that libvirt knows what it has to work with.

Short term workaround:

Until a new build of  qemu-system is available, you can disable loading of the vhost-net module, so libvirt won't bother trying to use it. Just create a file in /etc/modprobe.d (you could call it vhost-net.conf) containing this line:

   blacklist vhost-net

and if you want to unload it immediately, you can also run "rmmod vhost-net"; otherwise it won't be loaded during subsequent boots of the host.

Long term fix:

qemu-system-* need to either be configured with vhost-net support enabled, or their help text needs to be modified so that the vhost option isn't mentioned anywhere.
Comment 16 Arnold Wang 2012-03-08 13:55:49 EST
I'm pretty sure I bought a VT capable CPU and enabled in the BIOS. Any way, how I can verify that? I tried the following so far:

-bash-4.2# lsmod | grep kvm
kvm_intel             132336  0 
kvm                   401177  1 kvm_intel

-bash-4.2# egrep '^flags.*(vmx|svm)' /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
-bash-4.2#
Comment 17 Daniel Berrange 2012-03-08 14:05:56 EST
@Arnold  the virt-host-validate command will verify that you have VT correctly enabled. From those CPU flags it looks fine ('vmx' is present)
Comment 18 Arnold Wang 2012-03-08 14:27:59 EST
Since I'm only running libvirt-0.9.6-4.fc16.x86_64, virt-host-validate is not available to me. :-(
-bash-4.2# virt-host-validate
bash: virt-host-validate: command not found...

BTW, I tried manually use qemu-kvm, didn't know the existence of the difference, and I'm running into a different issue now. Well, I need figure out libvirt insist to use qemu-system-x86_64 even my machine is KVM capable. However that's a separate issue, I assume.
 
-bash-4.2# LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -S -M pc-0.14 -cpu core2duo,+lahf_lm,+rdtscp,+aes,+popcnt,+x2apic,+sse4.2,+sse4.1,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+pbe,+tm,+ht,+ss,+acpi,+ds -no-kvm -m 4096 -smp 1,sockets=1,cores=1,threads=1 -name Windows7 -uuid f6cddba1-b1ef-67d8-658b-e802d80352e5 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device lsi,id=scsi0,bus=pci.0,addr=0x7 -drive file=/var/lib/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/Windows7-1.img,if=none,id=drive-scsi0-0-0,format=raw,cache=none -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:7c:d2,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
char device redirected to /dev/pts/1
qemu-kvm: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: TUNGETIFF ioctl() failed: Bad file descriptor
TUNSETOFFLOAD ioctl() failed: Bad file descriptor
qemu-kvm: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: vhost-net requested but could not be initialized
qemu-kvm: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: Device 'tap' could not be initialized

I have the following kernel modules loaded.
-bash-4.2# lsmod | grep kvm
kvm_intel             132336  0 
kvm                   401177  1 kvm_intel
-bash-4.2# lsmod | grep vhost
vhost_net              33675  0 
macvtap                18183  1 vhost_net
tun                    22768  4 vhost_net
-bash-4.2# lsmod | grep tun
tun                    22768  4 vhost_net
-bash-4.2# lsmod | grep tap
macvtap                18183  1 vhost_net
macvlan                18569  1 macvtap
Comment 19 Arnold Wang 2012-03-08 14:53:58 EST
Ok, I "fixed" my problem. Since it's beyond my capability to figure out all the parameters to satisfy qemu-kvm manually, I took the short cut to create a new VM using the GUI. This time, I made sure it's using KVM and I could start the machine with virtio NIC.
I guess what happened was originally the VM was build with qemu option, for whatever reason. After all, the root cause is in libvirt. It need either reject "virtio" or change the virtualization type, in my view.
Comment 20 Laine Stump 2012-03-09 08:39:04 EST
(In reply to comment #19)
> After all, the root cause is in libvirt. It need either reject
> "virtio" or change the virtualization type, in my view.

As far as I understand things, that is incorrect. The virtio driver should work regardless of whether or not kvm is available/used. The two are independent of each other. As a matter of fact, the problem isn't that virtio isn't available in qemu-system, the problem is that one virtio optimization isn't available in qemu-system, but qemu-system advertises (via the help) that it is.
Comment 21 Arnold Wang 2012-03-09 23:51:06 EST
Thanks for the explanation.
Comment 22 Fedora Admin XMLRPC Client 2012-03-15 13:57:05 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 23 Fedora End Of Life 2013-01-16 15:43:51 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Cole Robinson 2013-02-11 16:58:16 EST
Sounds like the original reporter worked around their issue. Since we haven't heard any other reports, I'm guessing this doesn't error on F18 at least. If anyone can still reproduce, please open a new bug since this one has grown quite long.

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