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

Re: [Xen-devel] Powerdown problem on XEN | ACPI S5



Hi guys,
the good news is that the latest patched kernel now powers down my machine as expected. Thanks for all your input and help.

The console is still working and there's no need to hide the Intel IGD from dom0 to get proper powerdown.

I am however still unclear what this may mean further down the line? Are those patches someting I have to manually apply for every new kernel release that I'm going to install?

Or would those patches be something that makes it into the upstream kernel sources to then again drip downstream allowing me to use my distribution's sources (gentoo in my case) without change in the future?

Are there any negative knock-on effects / reduced functionalities to be expected from the patches I have applied?

Being kernel patches I assume they at least should have no effect on upgrading from XEN 4.2.2 to newer versions in the future.


Also just for reference in case someone else faces the same problem and stumbles across this thread please find a few comments / clarifications below to the questions I had raised and to Konrad's subsequent answers.

Am 15.08.13 22:26, schrieb Konrad Rzeszutek Wilk:
On Thu, Aug 15, 2013 at 09:28:24PM +0200, Atom2 wrote:
Hi guys,
thanks for your further input.

Following through Ben's mail below and Konrad's later mail
suggesting the same, I tried to get these patches in. I'd however
require your help before I feel I can safely proceed.

Please see below:

Am 15.08.13 03:58, schrieb Ben Guthro:
[...]
I admit, I don't know how the gentoo build system works, but the general
idea here is that you want to revert those 2 commits, and apply the third.

If you don't have a git tree, you can download the two commits from
these two links
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=c79c49826270b8b0061b2fca840fc3f013c8a78a
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=8eaffa67b43e99ae581622c5133e20b0f48bcef1

You'll want to apply them in reverse
After consultation with the manual I decided to give it a dry-run
before and check with you guys first. First of all, I assume I'm
righht that this is a patch to the *linux kernel* and not the
xen-sources as I could not find the referenced files in the xen
tree.

Right. You also need to compile the kernel. Usually I pluck the
/boot/config-my-exisitng-kernel-vresion and put it in the linux
directory as .config.
Extracting .config from a kernel image requires the kernel configuration option CONFIG_IKCONFIG. One can then either extract the .config through scripts/extract-ikconfig (located under the linux directory) or if additionally CONFIG_IKCONFIG_PROC is configured, by accessing /proc/config.gz.

In my case (and most likely for all gentoo users) it was even easier as I had originally built the running kernel myself and .config was readily available in the right directory anyways.


patch -p1 -R < c79c498.patch
vm-host # patch --dry-run -p1 -R < c79c498.patch
patching file arch/x86/xen/enlighten.c
Hunk #2 succeeded at 1431 (offset 14 lines).

I am slightly worried about the last message, not so much about the
offset, but rather only the "Hunk #2" success. Why is there no "Hunk
#1" when there's a "Hunk #2"?
That "Hunk #2" message seems to be harmless as a check of my patched sources against Konrad's diff attachement suggests. Still don't know where it comes from though.


patch -p1 -R < 8eaffa67.patch
vm-host # patch --dry-run -p1 -R < 8eaffa67.patch
patching file arch/x86/xen/enlighten.c
Hunk #1 succeeded at 1367 (offset 226 lines).
patching file arch/x86/xen/mmu.c
Hunk #1 succeeded at 434 (offset 19 lines).
Hunk #2 succeeded at 482 (offset 19 lines).
Hunk #3 succeeded at 495 (offset 19 lines).

That seems to be o.k. from my understanding?
A check against Konrad's diff attachment after running the final patch command again confirmed everything o.k.


Then apply the patch from
https://lkml.org/lkml/2012/2/10/229
For this patch I copied the complete text from the https address
above and copied it to a file named 229.patch. Then I issued the
following command:
vm-host # patch --dry-run -p1 -R < 229.patch
patching file arch/x86/include/asm/pgtable.h
Unreversed patch detected!  Ignore -R? [n]

Note that you had been using --dry-run which means that the changes
did NOT go in effect.

I am not sure what to make out of this? Could you please provide some input.
The issue was not the --dry-run (which I was aware of), but rather the -R option. This patch does not need to be *reversed* (the -R), but rather *applied* (as Ben had already suggested in his e-Mail). And that was what the message actually meant ...

I have also added a -b option to all patch commands (and clearly removed the --dry-run option for all patches) to create a backup copy just in case ...


Attaching the full part thanks to Martin Cerveny <martin@xxxxxxxxx>
doing it in another thread (about the Nvidia and CUDA).

You basically want those changes that the diff file has.

After the patching, if you run git diff you should see a similar
result to what the attached patch had.

Then just do 'make -j3141567891238901948248092840932480932; sudo make 
modules_install; sudo make
install;sudo grub2-mkconfig -o /boot/grub2/grub.cfg' and reboot the new
kernel.
I had to do this slightly differently, not only because I use grub instead of grub2 - but that's something Konrad could not possibly have been aware of.


Thanks and sorry for those probably dumb questions. I'm new to this
(automated) patching thing, and with a little help, the first time
usually works out well.

P.S.
No need to do the -j31415.. It should be just the amount of CPUs
you have.
Yeah, in my case it was just a -j9 using a 4-core CPU with hyperthreading


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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