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

Re: [Xen-devel] pv-ops domU not working with MSI interrupts on Nehalem


  • To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • From: Bruce Edge <bruce.edge@xxxxxxxxx>
  • Date: Sat, 2 Oct 2010 22:46:45 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 02 Oct 2010 22:47:40 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EbSlkMjRYpCTkyIfoYT1jMLFUsdbiVb4ECpuCFwVyZveD1cqBxLQp7/wHOQgl35w7Q wU52GC9M712SURBduAIU8aSNCfPmozd9R2keSwAs+8se9fMn76e8arQhq1xzMuisIe3q pBpLjmsSf5ZEIu+xH+k3qIS9GT3OyXyiSW0s4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Fri, Oct 1, 2010 at 4:30 PM, Bruce Edge <bruce.edge@xxxxxxxxx> wrote:
> On Fri, Oct 1, 2010 at 2:11 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
>> On Mon, Sep 27, 2010 at 08:52:39AM -0700, Bruce Edge wrote:
>>> One of our developers who is working on a tachyon driver is
>>> complaining that the pvops domU kernel is not working for these MSI
>>> interrupts.
>>> This is using the current head of xen/2.6.32.x on both a single
>>> Nahelam 920 and a dual E5540. This behavior is consistent with Xen
>>> 4.0.1, 4.0.2.rc1-pre and 4.1.
>>
>>
>> I just checked on my SuperMicro X8DTN, this combination
>>  - For Dom0, git commit fe999249 (2.6.32.18)
>>  - For DomU, devel/xen-pcifront-0.6 or devel/xen-pcifront-0.7
>
> Konrad,
>
> Apologies in advance for the rookie git questions.
>
> I'm assuming the git repos you mentioned are based on
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ?
>
> Your devel/xen-pcifront-0.7 isn't visible:
>
> %> git branch -r  | grep devel/xen-pcifront
>
>  origin/devel/xen-pcifront-0.1
>  origin/devel/xen-pcifront-0.2
>  origin/devel/xen-pcifront-0.3
>  origin/devel/xen-pcifront-0.4
>  origin/devel/xen-pcifront-0.5
>  origin/devel/xen-pcifront-0.6
>
>
> and your devel/xen-pcifront-0.6 forces a config restart:
>
> 0 %> make oldconfig
> scripts/kconfig/conf --oldconfig arch/x86/Kconfig
> *
> * Restart config...
> *
> *
> * General setup
> *
> Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
> Cross-compiler tool prefix (CROSS_COMPILE) [] (NEW) ^Cmake[1]: ***
> [oldconfig] Interrupt
> make: *** [oldconfig] Interrupt
>
> Is there a trick to avoiding the config restart?

Found the problem here - I was using a .config from a 2.6.32 kernel.
There's something in the 2.6.36 config parsing that declares it
invalid and starts over.
Starting with a clean 'make defconfig' and editing that works fine.

I had never see this behavior in kernel builds before. I thought the
.config files were always compatible between versions.

-Bruce

>
> -Bruce
>
>>  - For Hypervisor I used cs 21976, but found that the latest (22155) works 
>> too
>>
>> with which where I passed in PCI devices with legacy IRQ, MSI, and MSI-X. I 
>> tried
>> a combination of doing this with IOMMU (VT-d) and without - both cases these 
>> devices:
>>
>> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
>> Controller #1 (rev 02)
>> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
>> Controller #2 (rev 02)
>> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
>> Controller #3 (rev 02)
>> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
>> Controller #1 (rev 02)
>> 03:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet 
>> Controller (Copper) (rev 06)
>> 0a:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network 
>> Connection (rev 02)
>>
>> worked just fine (either defining pci=["..."] or just using pci-attach).
>>
>> But if I use the latest xen/next or xen/stable-2.6.32.x it does not look
>> that happy :-(
>>
>>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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