From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753537AbZHBU0d (ORCPT ); Sun, 2 Aug 2009 16:26:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752847AbZHBU0d (ORCPT ); Sun, 2 Aug 2009 16:26:33 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:37462 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752653AbZHBU0c (ORCPT ); Sun, 2 Aug 2009 16:26:32 -0400 From: "Rafael J. Wysocki" To: Christian Kujau Subject: Re: [Bug #13666] WARNING: at mm/page_alloc.c:1743 __alloc_pages_nodemask Date: Sun, 2 Aug 2009 22:26:51 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.31-rc5-rjw; KDE/4.2.4; x86_64; ; ) Cc: David Rientjes , Linux Kernel Mailing List , Andrew Morton , linux-ext4@vger.kernel.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908022226.52228.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday 02 August 2009, Christian Kujau wrote: > Hm, > > looks like this *is* reproducible. After a reboot, mounting the very > same ext4 filesystem triggers this WARNING again: > > [ 165.000603] ------------[ cut here ]------------ > [ 165.000726] WARNING: at mm/page_alloc.c:1749 __alloc_pages_nodemask+0x4c4/0x5a0() > [ 165.000853] Hardware name: Lenovo > [ 165.000944] Modules linked in: fuse acpi_cpufreq nfsd lockd nfs_acl auth_rpcgss sunrpc lm75 hwmon b43 usb_storage usb_libusual mac80211 cfg80211 uhci_hcd ehci_hcd tg3 ssb usbcore libphy nls_base > [ 165.002297] Pid: 2789, comm: mount Not tainted 2.6.31-rc4 #1 > [ 165.002397] Call Trace: > [ 165.002494] [] ? warn_slowpath_common+0x7a/0xc0 > [ 165.002601] [] ? __alloc_pages_nodemask+0x4c4/0x5a0 > [ 165.002708] [] ? warn_slowpath_null+0x20/0x40 > [ 165.002812] [] ? __alloc_pages_nodemask+0x4c4/0x5a0 > [ 165.002921] [] ? delayacct_end+0xa2/0xd0 > [ 165.003027] [] ? __get_free_pages+0x21/0x60 > [ 165.003132] [] ? match_number+0x3d/0xc0 > [ 165.003235] [] ? parse_options+0xe2/0x5d0 > [ 165.003340] [] ? out_of_line_wait_on_bit+0xbb/0xf0 > [ 165.003449] [] ? __wait_on_buffer+0x28/0x50 > [ 165.003552] [] ? ext4_fill_super+0x457/0x2670 > [ 165.003657] [] ? vsnprintf+0x516/0x820 > [ 165.003759] [] ? kobject_get+0x1d/0x40 > [ 165.003865] [] ? disk_name+0xd7/0xe0 > [ 165.003967] [] ? get_sb_bdev+0x15a/0x1a0 > [ 165.004107] [] ? ext4_fill_super+0x0/0x2670 > [ 165.004216] [] ? ext4_get_sb+0x2d/0x50 > [ 165.004315] [] ? ext4_fill_super+0x0/0x2670 > [ 165.004419] [] ? vfs_kern_mount+0x58/0xd0 > [ 165.004522] [] ? do_kern_mount+0x56/0x120 > [ 165.004625] [] ? do_mount+0x23a/0x750 > [ 165.004727] [] ? copy_mount_options+0x61/0x160 > [ 165.004831] [] ? sys_mount+0x9f/0x100 > [ 165.004934] [] ? syscall_call+0x7/0xb > [ 165.005044] ---[ end trace d2227ca6268a916a ]--- > [ 165.287930] EXT4-fs (dm-7): barriers enabled > > The whole dmesg and proc/meminfo is at: > http://nerdbynature.de/bits/2.6.31-rc4/ > > Note: "dm-7" is a dm-crypt device, backed by an external disk which is > connected via USB. The filesystem itself seems fine however, nothing > unusual except this warning so far... The patches supposed to fix this issue went in right before -rc5 AFAIC. Can you try to reproduce with -rc5? Rafael