Re: WARNING in vmap_page_range on alpha since 2.6.28

From: Thorsten Kranzkowski
Date: Sun Jan 11 2009 - 14:05:10 EST

Next message: Randy Dunlap: "Re: [PATCH -next] jbd2: fix printk format warning"
Previous message: Ingo Molnar: "Re: 2.6.29-rc1 does not boot"
In reply to: Tobias Klausmann: "WARNING in vmap_page_range on alpha since 2.6.28"
Next in thread: Ivan Kokshaysky: "Re: WARNING in vmap_page_range on alpha since 2.6.28"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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:
> [<fffffc0000377e48>] vmap_page_range+0x1b8/0x320
> [<fffffc0000379288>] __vmalloc_area_node+0xb8/0x1b0
> [<fffffc0000377fe4>] map_vm_area+0x34/0x60
> [<fffffc0000379320>] __vmalloc_area_node+0x150/0x1b0
> [<fffffc00003792cc>] __vmalloc_area_node+0xfc/0x1b0
> [<fffffc00004da5d4>] agp_add_bridge+0x1a4/0x610
> [<fffffc00005d2858>] agp_amdk7_probe+0x17c/0x2ec
> [<fffffc000049627c>] pci_device_probe+0x8c/0xc0
> [<fffffc00004ff1b8>] driver_probe_device+0xa8/0x230
> [<fffffc00004ff41c>] __driver_attach+0xdc/0xe0
> [<fffffc00004fe698>] bus_for_each_dev+0x78/0xd0
> [<fffffc00004ff340>] __driver_attach+0x0/0xe0
> [<fffffc00004fef5c>] driver_attach+0x2c/0x40
> [<fffffc00004fdccc>] bus_add_driver+0x28c/0x340
> [<fffffc00004ff6e4>] driver_register+0x94/0x1d0
> [<fffffc00004965e4>] __pci_register_driver+0x64/0xf0
> [<fffffc0000310084>] do_one_initcall+0x34/0x1e0
> [<fffffc00003db60c>] proc_register+0x6c/0x280
> [<fffffc00003db5f0>] proc_register+0x50/0x280
> [<fffffc00003db9bc>] create_proc_entry+0x7c/0x100
> [<fffffc000035597c>] register_irq_proc+0xbc/0xe0
> [<fffffc0000355a14>] init_irq_proc+0x74/0xa0
> [<fffffc0000311158>] kernel_thread+0x28/0x90
> [<fffffc0000310d84>] 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:
[<fffffc00003823e0>] vmap_page_range+0x1c4/0x264
[<fffffc0000381e0c>] alloc_pages_node+0x38/0x4c
[<fffffc00003824b4>] map_vm_area+0x34/0x58
[<fffffc0000382628>] __vmalloc_area_node+0x150/0x18c
[<fffffc00006e1bc8>] dm_ctl_ioctl+0x1c8/0x38c
[<fffffc00006dfe08>] dev_status+0x0/0x70
[<fffffc00003a14d8>] vfs_ioctl+0x3c/0xd0
[<fffffc00003a1ac4>] do_vfs_ioctl+0x558/0x5a8
[<fffffc00003a1b78>] sys_ioctl+0x64/0xa8
[<fffffc0000337708>] do_softirq+0x58/0x70
[<fffffc000031a404>] smp_percpu_timer_interrupt+0xa4/0xf0
[<fffffc00003a1b50>] sys_ioctl+0x3c/0xa8
[<fffffc0000310fa4>] 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:
[<fffffc00003823e0>] vmap_page_range+0x1c4/0x264
[<fffffc0000381e0c>] alloc_pages_node+0x38/0x4c
[<fffffc00003824b4>] map_vm_area+0x34/0x58
[<fffffc0000382628>] __vmalloc_area_node+0x150/0x18c
[<fffffc00006e1bc8>] dm_ctl_ioctl+0x1c8/0x38c
[<fffffc00006dfe08>] dev_status+0x0/0x70
[<fffffc00003a14d8>] vfs_ioctl+0x3c/0xd0
[<fffffc00003a1ac4>] do_vfs_ioctl+0x558/0x5a8
[<fffffc00003a1b78>] sys_ioctl+0x64/0xa8
[<fffffc0000392bf8>] sys_write+0x64/0x9c
[<fffffc00003a1b50>] sys_ioctl+0x3c/0xa8
[<fffffc0000310fa4>] 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 <linux/types.h>
-#include <linux/pci.h>
#include <asm/compiler.h>

/*

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@xxxxxxxxx |
| Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@xxxxxxxxxxxxxxxxxxxxxx [44.130.8.19] |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Next message: Randy Dunlap: "Re: [PATCH -next] jbd2: fix printk format warning"
Previous message: Ingo Molnar: "Re: 2.6.29-rc1 does not boot"
In reply to: Tobias Klausmann: "WARNING in vmap_page_range on alpha since 2.6.28"
Next in thread: Ivan Kokshaysky: "Re: WARNING in vmap_page_range on alpha since 2.6.28"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]