[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xci-devel] Porblem with disabling and then re-enabling a PT device in Windows
I am not sure i undertand how to test it... 1) Avoid doing FLR for the device - isn';t that done only when building the domain? does that happen when i disable the device in domU? 2) Don't build pciback - and then, i won't bind the wlan device to pciback? and change the xend scripts which check for it? 3) Comment out the relevant code - which code?? I also don't understand, how could it be that the pciback device is "messing" with it? isn't it supposed to be in-active when the device is being used in PT? Tom On Wed, Nov 25, 2009 at 4:12 PM, Kamala Narasimhan <Kamala.Narasimhan@xxxxxxxxxx> wrote: > There is a chance pciback is changing the bit you are referring to. To > confirm that, just for testing purpose you might want to avoid FLR for that > device or simply not build pciback or comment out relevant code in that > module whichever is easier and see if that helps. If it does, you can then > look into fixing the problem the right way. > > Kamala > >> -----Original Message----- >> From: xci-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xci-devel- >> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tom Rotenberg >> Sent: Wednesday, November 25, 2009 8:09 AM >> To: xen-devel@xxxxxxxxxxxxxxxxxxx; xci-devel@xxxxxxxxxxxxxxxxxxx >> Subject: [Xci-devel] Porblem with disabling and then re-enabling a PT >> device in Windows >> >> 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 > _______________________________________________ Xci-devel mailing list Xci-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/mailman/listinfo/xci-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |