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
|
Home