Re: Why doesn't Intel e1000 NIC work correctly in Windows XP?

[Dor Laor <dlaor@redhat.com>]

Not sure it might help but IIRC the original e1000 driver for windows 
had some bugs that were fixed if you'll download the most recent driver 
from Intel site. This was the case for the fully emulated e1000 qemu 
device and might help here too.

On 06/19/2011 03:29 PM, Flypen CloudMe wrote:
> Hi,
>
> Here are the command line:
>
> /usr/bin/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 2048 -smp
> 2,sockets=1,cores=2,threads=1 \
> -name winxp -uuid 23cd2751-8a30-dd34-db47-bfc8c76ccadb -nodefconfig
> -nodefaults \
> -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait
> -mon chardev=monitor,mode=readline \
> -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x5
> -device lsi,id=scsi1,bus=pci.0,addr=0x6 \
> -device lsi,id=scsi2,bus=pci.0,addr=0x7 -device
> lsi,id=scsi3,bus=pci.0,addr=0x8 \
> -drive file=/mnt/vmdisk/winxp.disk,if=none,id=drive-ide0-0-0,boot=on,format=raw,cache=none
> \
> -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \
> -drive file=/mnt/vmdisk/virtio-win-1.1.16.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none\
> -global isa-fdc.driveA=drive-fdc0-0-0 -drive
> file=/dev/sd1,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=/dev/sdb,if=none,id=drive-scsi0-0-1,format=raw,cache=none \
> -device scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1 \
> -drive file=/dev/sdc,if=none,id=drive-scsi0-0-2,format=raw,cache=none \
> -device scsi-disk,bus=scsi0.0,scsi-id=2,drive=drive-scsi0-0-2,id=scsi0-0-2 \
> -drive file=/dev/sdd,if=none,id=drive-scsi0-0-3,format=raw,cache=none \
> -device scsi-disk,bus=scsi0.0,scsi-id=3,drive=drive-scsi0-0-3,id=scsi0-0-3 \
> -drive file=/dev/sde,if=none,id=drive-scsi0-0-4,format=raw,cache=none \
> -device scsi-disk,bus=scsi0.0,scsi-id=4,drive=drive-scsi0-0-4,id=scsi0-0-4 \
> -drive file=/dev/sdf,if=none,id=drive-scsi3-0-0,format=raw,cache=none \
> -device scsi-disk,bus=scsi3.0,scsi-id=0,drive=drive-scsi3-0-0,id=scsi3-0-0 \
> -drive file=/mnt/vmdisk/D/1,if=none,id=drive-scsi0-0-6,format=raw,cache=none \
> -device scsi-disk,bus=scsi0.0,scsi-id=6,drive=drive-scsi0-0-6,id=scsi0-0-6 \
> -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb \
> -vnc 0.0.0.0:0 -k en-us -vga vmware -device
> pci-assign,host=02:00.0,id=hostdev0,configfd=18,bus=pci.0,addr=0x3 \
> -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
>
> The NIC and one SCSI controller (slot 7) has the same IRQ. The
> performance in XP is really bad. When writing traffic to the drive,
> the NIC can't be accessed, and ping will be also timeout.
> If I let the NIC has the different IRQ number, then everything is OK.
> Is it related to INTx model for XP?
>
> We rebuild the QEMU, and add the LSI SCSI controller support. Why does
> RHEL6 removes its support? Is this controller too old? Are there any
> emulated SCSI devices to replace it?
>
> Thanks,
> flypen
>
>
> On Thu, Jun 16, 2011 at 2:42 AM, Alex Williamson
> <alex.williamson@redhat.com>  wrote:
>>
>> On Wed, 2011-06-15 at 11:31 +0200, Jan Kiszka wrote:
>>> On 2011-06-15 10:04, Jan Kiszka wrote:
>>>> On 2011-06-15 02:54, Alex Williamson wrote:
>>>>> On Tue, 2011-06-14 at 16:11 +0800, Flypen CloudMe wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I use Redhat Enterprise Linux 6, and use the KVM that is released by
>>>>>> Redhat officially. The kernel version is 2.6.32-71.el6.x86_64.
>>>>>>
>>>>>> It seems that the IRQs are conflicted after reboot. The NIC and the
>>>>>> SCSI controller have the same IRQ number. If I re-install the NIC
>>>>>> driver, the IRQ number of the NIC will be assigned another value, then
>>>>>> it can work normally. Do we have a way to let the NIC and the SCSI
>>>>>> controller have different IRQ number in VM?
>>
>> Hmm, I'm still confused here.  I went back and double checked, and as I
>> thought, we disable the LSI SCSI controller in the RHEL6 KVM.  So I'm
>> curious what this device is.  Is it an assigned SCSI controller or is
>> there another one that we forgot to disable in RHEL or is this a
>> different version of KVM?  The config file or command line would be
>> handy here.
>>
>>>>> I'll see if I can reproduce and figure anything out.  Windows XP isn't a
>>>>> guest we concentrate on, especially with device assignment.  Are you
>>>>> using an AMD or Intel host system?  Does the same thing happen if you
>>>>> run the XP guest on an IDE controller?  It would be helpful to post the
>>>>> guest configuration, command line used or libvirt xml.  Also, you might
>>>>> try latest upstream qemu-kvm to see if the problem still exists.
>>
>> I tested with an 82578DM e1000e NIC on an Intel host system, and it
>> surprisingly worked just fine on the RHEL6.0 base.  This is with a 32bit
>> Windows XP SP3 install.  The device supports MSI, but windows only seems
>> to use it with INTx.  I did have to remove the emulated rtl8139 or else
>> I couldn't even boot due to BSODs in the guest.
>>
>>>
>>> Nonsense, can't t make a difference as the PIIX3 resets the routing to
>>> disable - which device-assignment does not deal with, but that's unrelated.
>>
>> Yep, someone has to write it at some point and device assignment will
>> catch that.
>>
>>> Try assigning a different slot to the passed-through adapter and the
>>> lsi. For me it helped to put the lsi on one slot behind the
>>> auto-assigned (-device lsi,addr=5).
>>>
>>> I guess classic device assignment cannot support INTx sharing as the
>>> kernel IRQ injection path does not inform user space about the device
>>> state /wrt IRQs. Should be catch and reject this, or try to fix it up be
>>> moving the assigned device around, Alex?
>>
>> I'm pretty sure we've looked at this path in the past and KVM will do
>> the right thing with respect to shared INTx in the guest (ie. KVM will
>> continue to assert the interrupt if it's been triggered by both
>> assignment and userspace until both de-assert).  Experimenting with a
>> RHEL guest I can make an assigned e1000e and emulated e1000 share an
>> interrupt.  It works, but performance is terrible and the assigned
>> device can get into a non-working state if the emulated device is
>> removed.  Perhaps there is still a path by which interrupts can get
>> turned off for the assigned device.
>>
>> Alex
>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html