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@xxxxxxxxxx> -----
Date: Tue, 09 Feb 2010 11:32:12 -0800
From: Yinghai Lu<yinghai@xxxxxxxxxx>
To: Ingo Molnar<mingo@xxxxxxx>, Thomas Gleixner<tglx@xxxxxxxxxxxxx>,
"H. Peter Anvin"<hpa@xxxxxxxxx>,
Andrew Morton<akpm@xxxxxxxxxxxxxxxxxxxx>,
Linus Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Jesse Barnes<jbarnes@xxxxxxxxxxxxxxxx>,
Christoph Lameter<cl@xxxxxxxxxxxxxxxxxxxx>,
linux-kernel@xxxxxxxxxxxxxxx, linux-pci@xxxxxxxxxxxxxxx,
Yinghai Lu<yinghai@xxxxxxxxxx>, stable@xxxxxxxxxx
Subject: [PATCH 01/35] x86: fix sci on ioapic 1
Thomas Renninger<trenn@xxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home