This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Apr 23 11:27:24 2024 >From spaans Tue Feb 2 21:04:42 2016 Envelope-to: lkml@grols.ch Delivery-date: Tue, 02 Feb 2016 20:56:36 +0100 Received: from srv.grols.ch [2a00:d10:4002:1::101] by squeeze.vs19.net with IMAP (fetchmail-6.3.21) for (single-drop); Tue, 02 Feb 2016 21:04:42 +0100 (CET) Received: from vger.kernel.org ([209.132.180.67]) by home.grols.ch with esmtp (Exim 4.84) (envelope-from ) id 1aQh3y-0002DL-Gb for lkml@grols.ch; Tue, 02 Feb 2016 20:56:36 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933921AbcBBT4c (ORCPT ); Tue, 2 Feb 2016 14:56:32 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:49387 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933421AbcBBT4b convert rfc822-to-8bit (ORCPT ); Tue, 2 Feb 2016 14:56:31 -0500 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u12JuNIS020422 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Feb 2016 19:56:24 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u12JuNPn031002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Feb 2016 19:56:23 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u12JuNkI005274; Tue, 2 Feb 2016 19:56:23 GMT Received: from olila.local.net-space.pl (/10.175.191.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Feb 2016 11:56:22 -0800 Date: Tue, 2 Feb 2016 20:56:16 +0100 From: Daniel Kiper To: "Li, Liang Z" Cc: David Vrabel , Andrew Cooper , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" , Jan Beulich , Tim Deeg Subject: Re: dom0 show call trace and failed to boot on HSW-EX platform Message-Id: <20160202195616.GI3485@olila.local.net-space.pl> References: <56B080C7.9070704@citrix.com> <56B08385.2060009@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-source-ip: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: -6.3 X-Spam-Score-Bar: ------ X-Spam-Report: Content analysis details: (-6.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high On Tue, Feb 02, 2016 at 01:15:13PM +0000, Li, Liang Z wrote: > > >> We found dom0 will crash when booing on HSW-EX server, the dom0 > > >> kernel version is v4.4. By debugging I found the your patch ' > > >> x86/xen: discard RAM regions above the maximum reservation' , which > > the commit ID is : f5775e0b6116b7e2425ccf535243b21 caused the regression. > > The debug message is listed below: > > >> > > ========================================================== > > >> (XEN) mm.c:884:d0v14 pg_owner 0 l1e_owner 0, but real_pg_owner -1 > > >> (XEN) mm.c:955:d0v14 Error getting mfn 1080000 (pfn > > >> ffffffffffffffff) from L1 > > >> (XEN) mm.c:1269:d0v14 Failure in alloc_l1_table: entry 0 > > >> (XEN) mm.c:2175:d0v14 Error while validating mfn 188d903 (pfn > > >> 17a7cc) for type > > >> (XEN) mm.c:3101:d0v14 Error -16 while pinning mfn 188d903 > > >> [ 33.768792] ------------[ cut here ]------------ > > >> WARNING: CPU: 14 PID: 1 at arch/x86/xen/multicalls.c:129 xen_mc_ > > >> [ 33.783809] Modules linked in: > > >> [ 33.787304] CPU: 14 PID: 1 Comm: swapper/0 Not tainted 4.4.0 #1 > > >> [ 33.793991] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, > > BIOS > > >> [ 33.805624] 0000000000000081 ffff88017d2537c8 ffffffff812ff954 > > 000000000000 > > >> [ 33.813961] 0000000000000000 0000000000000081 0000000000000000 > > ffff88017d25 > > >> [ 33.822300] ffffffff810ca120 ffffffff81cb7f00 ffff8801879ca280 > > 000000000000 > > >> [ 33.830639] Call Trace: > > >> [ 33.833457] [] dump_stack+0x48/0x64 > > >> [ 33.839277] [] warn_slowpath_common+0x90/0xd0 > > >> [ 33.846058] [] warn_slowpath_null+0x15/0x20 > > >> [ 33.852659] [] xen_mc_flush+0x1c3/0x1d0 > > >> [ 33.858858] [] xen_alloc_pte+0x20f/0x300 > > >> [ 33.865158] [] ? update_page_count+0x45/0x60 > > >> [ 33.871855] [] ? phys_pte_init+0x170/0x183 > > >> [ 33.878345] [] phys_pmd_init+0x2e6/0x389 > > >> [ 33.884649] [] phys_pud_init+0x2ad/0x3dc > > >> [ 33.890954] [] > > kernel_physical_mapping_init+0xec/0x211 > > >> [ 33.898613] [] init_memory_mapping+0x17d/0x2f0 > > >> [ 33.905496] [] ? > > __raw_callee_save___pv_queued_spin_unloc[2 > > 4;80H > > >> [ 33.914516] [] ? > > acpi_os_signal_semaphore+0x2e/0x32 > > >> [ 33.921889] [] arch_add_memory+0x48/0xf0 > > >> [ 33.928186] [] add_memory_resource+0x80/0x110 > > >> [ 33.934967] [] add_memory+0x7d/0xc0 > > >> [ 33.940787] [] > > acpi_memory_device_add+0x14f/0x237 > > > > We shouldn't be adding memory based on the ACPI tables. > > > > David > > To solve this issue, what's your suggestion, simply revert? Or with a workaround? Please do not blindly revert anything. It looks strange. Does this machine support memory hotplug? Anyway, bare metal memory hotplug stuff should not be used on dom0. I think that you should investigate why kernel attempts to hotplug memory at this stage. I suppose that it should not. If we know why then we will think how to fix it. Daniel