Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753632AbZAKTFI (ORCPT ); Sun, 11 Jan 2009 14:05:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751816AbZAKTEz (ORCPT ); Sun, 11 Jan 2009 14:04:55 -0500 Received: from relay2.mail.vrmd.de ([81.28.224.28]:52147 "EHLO relay2.mail.vrmd.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751934AbZAKTEy (ORCPT ); Sun, 11 Jan 2009 14:04:54 -0500 X-Greylist: delayed 1588 seconds by postgrey-1.27 at vger.kernel.org; Sun, 11 Jan 2009 14:04:53 EST Date: Sun, 11 Jan 2009 18:36:00 +0000 From: Thorsten Kranzkowski To: Linux Kernel Mailing List , linux-mm@kvack.org, klausman@schwarzvogel.de Subject: Re: WARNING in vmap_page_range on alpha since 2.6.28 Message-ID: <20090111183600.GA2728@ds20.borg.net> Reply-To: dl8bcu@dl8bcu.de Mail-Followup-To: dl8bcu@dl8bcu.de, Linux Kernel Mailing List , linux-mm@kvack.org, klausman@schwarzvogel.de References: <20090111141855.GA7416@eric.schwarzvogel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090111141855.GA7416@eric.schwarzvogel.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Relay-User: dl8bcu@dl8bcu.de Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7001 Lines: 172 On Sun, Jan 11, 2009 at 03:18:55PM +0100, Tobias Klausmann wrote: > Hi! > > I've stumbled across this WARNING: when booting 2.6.28 + patch > on my alpha. This happens consistently (i.e. on every boot) and > keeps happening while the machine is booted: > > ------------[ cut here ]------------ > WARNING: at mm/vmalloc.c:104 vmap_page_range+0x1b8/0x320() > Modules linked in: > fffffc007f03b968 0000000000000003 fffffc0000377e48 fffffffc00002000 > fffffffc00008000 0000000000000003 6761705f70616d76 2b65676e61725f65 > 78302f3862317830 0000000000303233 fffffc00006f0828 0000000000000000 > fffffc00006efcd8 fffffc00006efcd8 fffffc00006f0830 0000000000000000 > 0000000000000000 fffffc00006efd18 0000000000000001 00000000000200d2 > 0000000000000000 0000000000000000 0000000000000001 0000000000000044 > Trace: > [] vmap_page_range+0x1b8/0x320 > [] __vmalloc_area_node+0xb8/0x1b0 > [] map_vm_area+0x34/0x60 > [] __vmalloc_area_node+0x150/0x1b0 > [] __vmalloc_area_node+0xfc/0x1b0 > [] agp_add_bridge+0x1a4/0x610 > [] agp_amdk7_probe+0x17c/0x2ec > [] pci_device_probe+0x8c/0xc0 > [] driver_probe_device+0xa8/0x230 > [] __driver_attach+0xdc/0xe0 > [] bus_for_each_dev+0x78/0xd0 > [] __driver_attach+0x0/0xe0 > [] driver_attach+0x2c/0x40 > [] bus_add_driver+0x28c/0x340 > [] driver_register+0x94/0x1d0 > [] __pci_register_driver+0x64/0xf0 > [] do_one_initcall+0x34/0x1e0 > [] proc_register+0x6c/0x280 > [] proc_register+0x50/0x280 > [] create_proc_entry+0x7c/0x100 > [] register_irq_proc+0xbc/0xe0 > [] init_irq_proc+0x74/0xa0 > [] kernel_thread+0x28/0x90 > [] entSys+0xa4/0xc0 > > ---[ end trace 9863e03dd539368c ]--- I see similar traces: ------------[ cut here ]------------ WARNING: at /export/data/scm/linux-2.6/mm/vmalloc.c:104 vmap_page_range+0x1c4/0x264() Modules linked in: fffffc007e303ae8 0000000000000000 fffffc00003823e0 fffffffc00188000 fffffc0000aee000 fffffc0000a57ac0 6761705f70616d76 2b65676e61725f65 78302f3463317830 0000000000343632 fffffc0000a58fc8 00000000000200d2 0000000000000000 0000000000000000 0000000000000001 0000000000000044 fffffc0000a57c00 0000000000000000 0000000000000000 00000000000200d2 ffffffffffe80000 0000000000000001 0000000000000000 fffffffc00000000 Trace: [] vmap_page_range+0x1c4/0x264 [] alloc_pages_node+0x38/0x4c [] map_vm_area+0x34/0x58 [] __vmalloc_area_node+0x150/0x18c [] dm_ctl_ioctl+0x1c8/0x38c [] dev_status+0x0/0x70 [] vfs_ioctl+0x3c/0xd0 [] do_vfs_ioctl+0x558/0x5a8 [] sys_ioctl+0x64/0xa8 [] do_softirq+0x58/0x70 [] smp_percpu_timer_interrupt+0xa4/0xf0 [] sys_ioctl+0x3c/0xa8 [] entSys+0xa4/0xc0 ---[ end trace a7919e7f17c0a725 ]--- ------------[ cut here ]------------ WARNING: at /export/data/scm/linux-2.6/mm/vmalloc.c:104 vmap_page_range+0x1c4/0x264() Modules linked in: fffffc007e303ae8 0000000000000000 fffffc00003823e0 fffffffc00190000 fffffc0000aee000 fffffc0000a57ac0 6761705f70616d76 2b65676e61725f65 78302f3463317830 0000000000343632 fffffc0000a58fc8 00000000000200d2 0000000000000000 0000000000000000 0000000000000001 0000000000000044 fffffc0000a57c00 0000000000000000 0000000000000000 00000000000200d2 ffffffffffe80000 0000000000000001 0000000000000000 fffffffc00000000 Trace: [] vmap_page_range+0x1c4/0x264 [] alloc_pages_node+0x38/0x4c [] map_vm_area+0x34/0x58 [] __vmalloc_area_node+0x150/0x18c [] dm_ctl_ioctl+0x1c8/0x38c [] dev_status+0x0/0x70 [] vfs_ioctl+0x3c/0xd0 [] do_vfs_ioctl+0x558/0x5a8 [] sys_ioctl+0x64/0xa8 [] sys_write+0x64/0x9c [] sys_ioctl+0x3c/0xa8 [] entSys+0xa4/0xc0 ---[ end trace a7919e7f17c0a725 ]--- For me they are occurring during invocation of 'lvm vgchange -a y'. The first call also fails, i.e. '0 volume groups activated', while a second call succeeds and activates both of the VGs it should handle. The traces above were taken from dmesg. They are not the first ones as there are quite a lot of them (perhaps one for every block device checked by the lvm tool?) and so the initial ones already escaped the message buffer. > Here's a full dmesg: > http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/dmesg_post_boot.txt > > Note that it happens again later in the same dmesg. The messages > always mention page allocation at the top of the trace. > > The patch mentioned above is commit > 1684f5ddd4c0c754f52c78eaa2c5c69ad09fb18c which fixes compilation > on alpha (see http://bugzilla.kernel.org/show_bug.cgi?id=12289) > The patch I used is here: > http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/pci.patch this is my local fix to this build problem: diff --git a/arch/alpha/include/asm/core_tsunami.h b/arch/alpha/include/asm/core_tsunami.h index 58d4fe4..8e39ecf 100644 --- a/arch/alpha/include/asm/core_tsunami.h +++ b/arch/alpha/include/asm/core_tsunami.h @@ -2,7 +2,6 @@ #define __ALPHA_TSUNAMI__H__ #include -#include #include /* I think some of the other core_*.h files need it, too. > Here's my config: > http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/config.txt > shortened by grep ^C: > http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/config-shortened.txt > > The normal console output (catched via serial console) is here: > http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/console_output.txt > > The machine in question is a Samsung UP1500. CPU is EV68AL on an > ALI chipset (ali15x3). DS20, dual EV6 > Last kernel to work perfectly is a vanilla 2.6.27.10. > > Before I dig into a rather time-consuming bisect, I'd like to > hear informed opinions :) bye, Thorsten -- | Thorsten Kranzkowski Internet: dl8bcu@dl8bcu.de | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] | -- 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/