Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752320AbZL3GVq (ORCPT ); Wed, 30 Dec 2009 01:21:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752196AbZL3GVp (ORCPT ); Wed, 30 Dec 2009 01:21:45 -0500 Received: from mail-iw0-f171.google.com ([209.85.223.171]:58206 "EHLO mail-iw0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751974AbZL3GVo convert rfc822-to-8bit (ORCPT ); Wed, 30 Dec 2009 01:21:44 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SdmUxI63yFxE6MX+mTkMkFo5qIyUB/JaYw26n6IFCJ5+yj51TuTfqKxB0SC5JP0xyJ Q1rHoyTkWvyztHdsE6iZLPEYyqmx/b4VWjlPmntw+KzLt+i6n3s/LF7JvI3CSkng7BaV OFDxpi0IYy8qVUJE5SWLqGzz+HQcB5r6t8Nzk= MIME-Version: 1.0 In-Reply-To: References: <20091229094202.25818e9b@nehalam> Date: Wed, 30 Dec 2009 15:21:43 +0900 Message-ID: <2f11576a0912292221r7ba59e9dw431c7b43b578a04@mail.gmail.com> Subject: Re: ACPI warning from alloc_pages_nodemask on boot (2.6.33 regression) From: KOSAKI Motohiro To: Len Brown Cc: Stephen Hemminger , linux-acpi@vger.kernel.org, Linux Kernel Mailing List , linux-mm@kvack.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5566 Lines: 102 >> [ ? ?1.611664] ACPI Warning: Incorrect checksum in table [OEMB] - 94, should be 8C (20091214/tbutils-314) >> [ ? ?1.611698] ACPI: SSDT 00000000bf7980c0 00403 (v01 DpgPmm ?P001Ist 00000011 INTL 20060113) >> [ ? ?1.613966] ACPI: SSDT 00000000bf7984d0 00403 (v01 DpgPmm ?P002Ist 00000012 INTL 20060113) >> [ ? ?1.616242] ACPI: SSDT 00000000bf7988e0 00403 (v01 DpgPmm ?P003Ist 00000012 INTL 20060113) >> [ ? ?1.618526] ACPI: SSDT 00000000bf798cf0 00403 (v01 DpgPmm ?P004Ist 00000012 INTL 20060113) >> [ ? ?1.620817] ACPI: SSDT 00000000bf799100 00403 (v01 DpgPmm ?P005Ist 00000012 INTL 20060113) >> [ ? ?1.623112] ACPI: SSDT 00000000bf799510 00403 (v01 DpgPmm ?P006Ist 00000012 INTL 20060113) >> [ ? ?1.625409] ACPI: SSDT 00000000bf799920 00403 (v01 DpgPmm ?P007Ist 00000012 INTL 20060113) >> [ ? ?1.627734] ACPI: SSDT 00000000bf799d30 00403 (v01 DpgPmm ?P008Ist 00000012 INTL 20060113) >> [ ? ?1.630020] ------------[ cut here ]------------ >> [ ? ?1.630026] WARNING: at mm/page_alloc.c:1812 __alloc_pages_nodemask+0x617/0x730() > > ? ? ? ?if (order >= MAX_ORDER) { > ? ? ? ? ? ? ? ?WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); > ? ? ? ? ? ? ? ?return NULL; > ? ? ? ?} > > I don't know what the mm alloc code is complaining about here. first, exceeding MAX_ORDER makes to return NULL since linux 1.x. then alloc_pages(MAX_ORDER) is wrong usage generally, but we hope to allow following usage: page = alloc_pages(__GFP_nowarn, big-order) if (!page) page = alloc_pages(small-order) It is the reason of __GFP_NOWARN check. I guess ACPI don't need large `contenious' memory. > >> [ ? ?1.630028] Hardware name: System Product Name >> [ ? ?1.630029] Modules linked in: >> [ ? ?1.630032] Pid: 1, comm: swapper Not tainted 2.6.33-rc2 #4 >> [ ? ?1.630034] Call Trace: >> [ ? ?1.630038] ?[] warn_slowpath_common+0x78/0xb0 >> [ ? ?1.630041] ?[] warn_slowpath_null+0xf/0x20 >> [ ? ?1.630044] ?[] __alloc_pages_nodemask+0x617/0x730 >> [ ? ?1.630048] ?[] alloc_page_interleave+0x34/0x90 >> [ ? ?1.630050] ?[] alloc_pages_current+0xc4/0xd0 >> [ ? ?1.630053] ?[] __get_free_pages+0x9/0x50 >> [ ? ?1.630055] ?[] __kmalloc+0x1bb/0x1f0 >> [ ? ?1.630059] ?[] ? trace_hardirqs_on+0xd/0x10 >> [ ? ?1.630064] ?[] acpi_os_allocate+0x25/0x27 >> [ ? ?1.630067] ?[] acpi_ex_load_op+0xd8/0x260 >> [ ? ?1.630070] ?[] acpi_ex_opcode_1A_1T_0R+0x25/0x4b >> [ ? ?1.630073] ?[] acpi_ds_exec_end_op+0xea/0x3d6 >> [ ? ?1.630076] ?[] acpi_ps_parse_loop+0x7d9/0x95f >> [ ? ?1.630079] ?[] ? acpi_ds_call_control_method+0x166/0x1d7 >> [ ? ?1.630082] ?[] acpi_ps_parse_aml+0x9a/0x2b9 >> [ ? ?1.630085] ?[] acpi_ps_execute_method+0x1c8/0x29a >> [ ? ?1.630088] ?[] acpi_ns_evaluate+0xe1/0x1a8 >> [ ? ?1.630090] ?[] acpi_evaluate_object+0xf9/0x1f2 >> [ ? ?1.630094] ?[] acpi_processor_set_pdc+0x1be/0x1e8 >> [ ? ?1.630097] ?[] early_init_pdc+0x9/0xf >> [ ? ?1.630100] ?[] acpi_ns_walk_namespace+0xb9/0x187 >> [ ? ?1.630102] ?[] ? early_init_pdc+0x0/0xf >> [ ? ?1.630105] ?[] ? early_init_pdc+0x0/0xf >> [ ? ?1.630108] ?[] acpi_walk_namespace+0x85/0xbf >> [ ? ?1.630111] ?[] ? acpi_init+0x0/0x12f >> [ ? ?1.630113] ?[] ? acpi_init+0x0/0x12f >> [ ? ?1.630116] ?[] acpi_early_processor_set_pdc+0x3a/0x3c >> [ ? ?1.630119] ?[] acpi_bus_init+0xb5/0x1de >> [ ? ?1.630123] ?[] ? kobject_create_and_add+0x3e/0x80 >> [ ? ?1.630126] ?[] ? genhd_device_init+0x0/0x7b >> [ ? ?1.630128] ?[] ? acpi_init+0x0/0x12f >> [ ? ?1.630131] ?[] acpi_init+0x71/0x12f >> [ ? ?1.630134] ?[] do_one_initcall+0x37/0x1a0 >> [ ? ?1.630137] ?[] kernel_init+0x166/0x1bc >> [ ? ?1.630140] ?[] kernel_thread_helper+0x4/0x10 >> [ ? ?1.630144] ?[] ? restore_args+0x0/0x30 >> [ ? ?1.630147] ?[] ? kernel_init+0x0/0x1bc >> [ ? ?1.630149] ?[] ? kernel_thread_helper+0x0/0x10 >> [ ? ?1.630156] ---[ end trace f17e946d22a56015 ]--- >> [ ? ?1.630159] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.P009._OSC] (Node ffff8801b9069c20), AE_NO_MEMORY >> [ ? ?1.630196] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.P009._PDC] (Node ffff8801b9069c00), AE_NO_MEMORY > > We've changed both the _OSC and _PDC code in this release. > In particular, _PDC is being evaluated earler than last release > in an attempt to be more Windows compatible... > > Stephen, > Please attach the output from acpidump to a new bugzilla entry > and point this thread to it. > > thanks, > Len Brown, Intel Open Source Technology Center > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > Please read the FAQ at ?http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/