Re: Powerdown problem on XEN | ACPI S5

[Atom2 <ariel.atom2@web2web.at>]

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@c-home.cz>
> 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
>>