[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xci-devel] Porblem with disabling and then re-enabling a PT device in Windows


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx, xci-devel@xxxxxxxxxxxxxxxxxxx
  • From: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
  • Date: Wed, 25 Nov 2009 15:08:37 +0200
  • Cc:
  • Delivery-date: Wed, 25 Nov 2009 05:08:35 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KXursXI5oxYsy+FGQfiDcTTl23Il0h/AbT1LV0urt6c7paVwqpNfur0Q/gKqtFyo99 NRpxCwhWSZ4/uueWMkYh4mM19oYzY0FWIR9RCRpy+xCUCHjIk/brKMi3dbDgqj7rBilz INkPRp5GvPkiZW+lGO0O5DggzjSYcQ8Fg4CjM=
  • List-id: xci-devel.lists.xensource.com

Hi All,

(This is a continuation to my previous mail, but since it looks like a
different problem - i decided to open a new thread for it)

----
Problem Description:
----
I am doing pass-through of an Intel wireless LAN device to a Windows
XP domU (my machine is Dell e6400), and it looks like it's working ok.
Then, i disable the device using Windows device manager, and the
device is now disabled, after that i re-enable the device, and Windows
re-enables the device correctly. However, the wlan device seems to
malfunction (it can't turn on the WiFi of the computer), and can't
connect to wireless networks.
I tried it, both with MSI translation on, and with MSI translation off
- it doesn't matter.

----
My analysis:
----
1) Well, taking a look at the real PCI config space, before disable
and after the (last) enable, shows that the difference is at the Intx
bit (read-only bit 3 at status register (offset 0x6) at the PCI config
space). Before disable, that bit was 0, and after the last enable that
bit was 1.
This, according to my understanding, means that the device is
asserting it's IntX , and probably waiting for someone to handle it,
no?

2) When i tried to track when did this bit was changed - i added a
code which in every PCI config read, checks if that bit was changed -
and added a print when it changed. The proper lines in the qemu log
looks like this:
...
pt_pci_read_config: [00:01.0]: address=00f0 val=0x00000000 len=2
ACPI PCI hotplug: read addr=0x10c6, val=0x0f.
ACPI PCI hotplug: read addr=0x10c6, val=0x0f.
pt_pci_read_config: TEST CODE: STATUS CHNAGED! OLD: 0x10, NEW: 0x18
pt_pci_read_config: [00:01.0]: address=0000 val=0x00008086 len=2
...

This implies that the bit was changed, about the same time that
Windows tried to start using it (because, i assume that it tried using
it, just after questioning the ACPI for the existence of the device).
No?


Can someone help me with this?

(BTW - i am using Xen 3.4)

Tom

_______________________________________________
Xci-devel mailing list
Xci-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xci-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.