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?

For right now, yes.
> 
> 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?

That is the goal. The way that the x86 maintainer wanted this to be done is
to have some sort of bit lookup "box". Were the generic code does some
form of pte_wc(pte) and we lookup in the PAT for the index bit for WC.
And vice-versa to pte_wb(pte). The complication is that there is also
the PSE bit to think off. It is not as simple as it sounds.

CC-ing Stefan Bader who took a stab at it. Maybe he had a chance to
look in this a bit more.

(sorry if this is confusing, the WC stands for Write Combine -
while WB is WriteBack. WC is heavily used in graphics).
> 
> Are there any negative knock-on effects / reduced functionalities to
> be expected from the patches I have applied?

No. The opposite actually.
> 
> 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.

Correct.
> 
> 
> 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.

Thanks!
> 
> 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
> >>