Re: SOLVED: Re: Issue with pv_ops Kernel 2.6.31.6 and Xen [yinghai@kernel.org: [PATCH 01/35] x86: fix sci on ioapic 1]

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 02/16/2010 10:10 AM, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 14, 2010 at 12:12:30AM +0100, Marcial Rion wrote:
>    
>> Konrad Rzeszutek Wilk wrote:
>>      
>>> FYI.
>>>
>>> ----- Forwarded message from Yinghai Lu<yinghai@kernel.org>  -----
>>>
>>> Date: Tue, 09 Feb 2010 11:32:12 -0800
>>> From: Yinghai Lu<yinghai@kernel.org>
>>> To: Ingo Molnar<mingo@elte.hu>, Thomas Gleixner<tglx@linutronix.de>,
>>> 	"H. Peter Anvin"<hpa@zytor.com>,
>>> 	Andrew Morton<akpm@linux-foundation.org>,
>>> 	Linus Torvalds<torvalds@linux-foundation.org>
>>> Cc: Jesse Barnes<jbarnes@virtuousgeek.org>,
>>> 	Christoph Lameter<cl@linux-foundation.org>,
>>> 	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
>>> 	Yinghai Lu<yinghai@kernel.org>, stable@kernel.org
>>> Subject: [PATCH 01/35] x86: fix sci on ioapic 1
>>>
>>> Thomas Renninger<trenn@suse.de>  reported on IBM x3330
>>>
>>> booting a latest kernel on this machine results in:
>>>
>>> PCI: PCI BIOS revision 2.10 entry at 0xfd61c, last bus=1
>>> PCI: Using configuration type 1 for base access bio: create slab<bio-0>  at 0
>>> ACPI: SCI (IRQ30) allocation failed
>>> ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20090903/evevent-161)
>>> ACPI: Unable to start the ACPI Interpreter
>>>
>>> Later all kind of devices fail...
>>>
>>> and bisect it down to this commit:
>>> commit b9c61b70075c87a8612624736faf4a2de5b1ed30
>>>
>>>      x86/pci: update pirq_enable_irq() to setup io apic routing
>>>
>>> it turns out we need to set irq routing for the sci on ioapic1 early.
>>>
>>>        
>> Yes, this did the trick. Introduced the code changes manually in the
>>      
> That is great.
>
> .. snip..
>    
>> Question: Is it known when this piece of code will be introduced in the
>> "pv_ops Kernel tree"?
>>      
> Hmm.. Jeremy's plans are to re-base the pvops changes that went in
> 2.6.31.6 onto 2.6.32. The reason being that 2.6.32 has been choosen by
> many distributions as their next vehicle for release. The patches being
> mostly, if possible, related only to Xen.
>
> The patch I forwarded to you is targetted for 2.6.33 so it would not appear
> normally in 2.6.32 tree unles Greg KH choose to back-port it in. Greg is
> the maintainer of the 2.6.32 stable tree.
>
> I would recommend you e-mail Greg KH with this e-mail, explain your
> situation  and ask him if he wouldn't mind merging the patch in.
> Thought you might need to do some of the work yourself
> (as in, merge the patch in an earlier kernel) - it seems you already
> have done this so hopefully that shouldn't be a problem.
>
> Try it that way, as this way also the distributions will pick up the fix
> and you would be able to load any new distro on your box without having
> to manually recompile the kernel and such.
>    

Is that one change enough to fix the reported problem?  Can we just 
cherry-pick it over?  Or does it need a lot of supporting patches?

> Then when Jeremy revs up the xen/next tree to next stable rev (I think
> he will do this, not sure?), it will automatically be picked up (if Greg picks it up in his tree).
>    

Yes.  At the moment xen/next is based on plain 2.6.32 because that is 
also an ancestor version of mainline git development.  Once the 2.6.32 
tree basically works (which should be close), then I can merge all the 
stable branch changes onto it and call it "xen/stable" or something.

     J