Re: Powerdown problem on XEN | ACPI S5

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Aug 15, 2013 at 11:39:14PM +0200, Atom2 wrote:
> 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?

Could you refresh my memory of which ones? Can you just do a git diff
please on your Linux tree?
> 
> 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
> >>