I shouldn't have suggested that you build without pciback; I got carried away
trying to make it simple for you :-); Obviously you would need it and I should
have stopped with suggesting that you tweak it.
Here is the thought process that led to my suggestion -
Clearly, that bit is getting changed as indicated in your log. It is unlikely
that the guest is triggering that change which makes pciback a potential
candidate to suspect as it does change pci configuration space bits. I need to
add some tracing and look at the path of execution to answer some of your
specific questions accurately and I won't be able to do that right now but I
can give some context to help you based on what I have experienced in
comparable situation and based on that I would say pciback is one place to
suspect. To be a bit more specific I would say look into
pciback_enable_msi/pciback_disable_msi code, add some tracing there, observe
whether or not that code path is taken when the device is disabled/reenabled
within guest etc. To reiterate, these are mere suggestions but looks plausible
based on prior observations.
Kamala
> -----Original Message-----
> From: Tom Rotenberg [mailto:tom.rotenberg@xxxxxxxxx]
> Sent: Wednesday, November 25, 2009 9:22 AM
> To: Kamala Narasimhan
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; xci-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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
|
Home