From mboxrd@z Thu Jan 1 00:00:00 1970 From: Atom2 Subject: Re: Powerdown problem on XEN | ACPI S5 Date: Thu, 15 Aug 2013 23:39:14 +0200 Message-ID: <520D4A82.7090304@web2web.at> References: <520BD621.1040701@web2web.at> <520BD80B.4060101@citrix.com> <520BDCE4.3040803@web2web.at> <520BE5FA.8040306@citrix.com> <520BE76A.9010905@web2web.at> <20130814203751.GA7959@phenom.dumpdata.com> <520BFCFA.4050902@web2web.at> <520D2BD8.6050606@web2web.at> <20130815202650.GG5337@konrad-lan.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VA5GQ-0002EE-Mw for xen-devel@lists.xenproject.org; Thu, 15 Aug 2013 21:39:26 +0000 In-Reply-To: <20130815202650.GG5337@konrad-lan.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Andrew Cooper , Ian Campbell , Ben Guthro , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org 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 > 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 >>