Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote:
> Arjan van de Ven wrote:
>> Gabriel C wrote:
>>> Arjan van de Ven wrote:
Gabriel C wrote:
> Laurent Riffard wrote:
>> Le 16.02.2008 09:25, Andrew Morton a écrit :
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
> [..]
>
> I'm getting that in mainline now on one of my older laptops also.
we fixed the cause of the machine you quoted; so I suspect yours is
different..
Can you get me your stacktrace ? Can you try the patch from this thread to
show
what memory the offender tries to access ?
>>> Arjan , sorry for the lag.
>>>
>>> With your patch from http://marc.info/?l=linux-kernel=120336371506283=2
>>> I don't have a warning anymore.
>>>
>> that is ... odd since it's the same in theory, just with some added printk's
>> ;-(
>>
>
> hmm but in theory only that part of your patch only should do the same , no ?
>
> if (page_is_ram(pfn)) {
> printk(..)
> }
>
> I'm going to try that.
>
>
With only that part I get the waring again.
But I see the printk() twice so I guess this should be in general an WARN_ON() ?
http://frugalware.org/~crazy/dmesg/dmesg_with_patch_2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Arjan van de Ven wrote:
> Gabriel C wrote:
>> Arjan van de Ven wrote:
>>> Gabriel C wrote:
Laurent Riffard wrote:
> Le 16.02.2008 09:25, Andrew Morton a écrit :
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
>>> we fixed the cause of the machine you quoted; so I suspect yours is
>>> different..
>>> Can you get me your stacktrace ? Can you try the patch from this thread to
>>> show
>>> what memory the offender tries to access ?
>> Arjan , sorry for the lag.
>>
>> With your patch from http://marc.info/?l=linux-kernel=120336371506283=2
>> I don't have a warning anymore.
>>
>
> that is ... odd since it's the same in theory, just with some added printk's
> ;-(
>
hmm but in theory only that part of your patch only should do the same , no ?
if (page_is_ram(pfn)) {
printk(..)
}
I'm going to try that.
Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote: Arjan van de Ven wrote: Gabriel C wrote: Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ [..] I'm getting that in mainline now on one of my older laptops also. we fixed the cause of the machine you quoted; so I suspect yours is different.. Can you get me your stacktrace ? Can you try the patch from this thread to show what memory the offender tries to access ? Arjan , sorry for the lag. With your patch from http://marc.info/?l=linux-kernel=120336371506283=2 I don't have a warning anymore. that is ... odd since it's the same in theory, just with some added printk's ;-( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Arjan van de Ven wrote: > Gabriel C wrote: >> Laurent Riffard wrote: >>> Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ > >> [..] >> >> I'm getting that in mainline now on one of my older laptops also. > > we fixed the cause of the machine you quoted; so I suspect yours is > different.. > Can you get me your stacktrace ? Can you try the patch from this thread to > show > what memory the offender tries to access ? Arjan , sorry for the lag. With your patch from http://marc.info/?l=linux-kernel=120336371506283=2 I don't have a warning anymore. There are the 2 dmesg's , one from 2.6.25-rc3 and other from 2.6.25-rc3+your patch: http://frugalware.org/~crazy/dmesg/dmesg http://frugalware.org/~crazy/dmesg/dmesg_with_patch It seems I'm not alone with that :) Have a look at http://lkml.org/lkml/2008/2/24/265 Regards, Gabriel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Arjan van de Ven wrote: Gabriel C wrote: Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ [..] I'm getting that in mainline now on one of my older laptops also. we fixed the cause of the machine you quoted; so I suspect yours is different.. Can you get me your stacktrace ? Can you try the patch from this thread to show what memory the offender tries to access ? Arjan , sorry for the lag. With your patch from http://marc.info/?l=linux-kernelm=120336371506283w=2 I don't have a warning anymore. There are the 2 dmesg's , one from 2.6.25-rc3 and other from 2.6.25-rc3+your patch: http://frugalware.org/~crazy/dmesg/dmesg http://frugalware.org/~crazy/dmesg/dmesg_with_patch It seems I'm not alone with that :) Have a look at http://lkml.org/lkml/2008/2/24/265 Regards, Gabriel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote: Arjan van de Ven wrote: Gabriel C wrote: Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ [..] I'm getting that in mainline now on one of my older laptops also. we fixed the cause of the machine you quoted; so I suspect yours is different.. Can you get me your stacktrace ? Can you try the patch from this thread to show what memory the offender tries to access ? Arjan , sorry for the lag. With your patch from http://marc.info/?l=linux-kernelm=120336371506283w=2 I don't have a warning anymore. that is ... odd since it's the same in theory, just with some added printk's ;-( -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Arjan van de Ven wrote:
Gabriel C wrote:
Arjan van de Ven wrote:
Gabriel C wrote:
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
we fixed the cause of the machine you quoted; so I suspect yours is
different..
Can you get me your stacktrace ? Can you try the patch from this thread to
show
what memory the offender tries to access ?
Arjan , sorry for the lag.
With your patch from http://marc.info/?l=linux-kernelm=120336371506283w=2
I don't have a warning anymore.
that is ... odd since it's the same in theory, just with some added printk's
;-(
hmm but in theory only that part of your patch only should do the same , no ?
if (page_is_ram(pfn)) {
printk(..)
}
I'm going to try that.
Gabriel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote:
Arjan van de Ven wrote:
Gabriel C wrote:
Arjan van de Ven wrote:
Gabriel C wrote:
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
we fixed the cause of the machine you quoted; so I suspect yours is
different..
Can you get me your stacktrace ? Can you try the patch from this thread to
show
what memory the offender tries to access ?
Arjan , sorry for the lag.
With your patch from http://marc.info/?l=linux-kernelm=120336371506283w=2
I don't have a warning anymore.
that is ... odd since it's the same in theory, just with some added printk's
;-(
hmm but in theory only that part of your patch only should do the same , no ?
if (page_is_ram(pfn)) {
printk(..)
}
I'm going to try that.
With only that part I get the waring again.
But I see the printk() twice so I guess this should be in general an WARN_ON() ?
http://frugalware.org/~crazy/dmesg/dmesg_with_patch_2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote: Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ [..] I'm getting that in mainline now on one of my older laptops also. we fixed the cause of the machine you quoted; so I suspect yours is different.. Can you get me your stacktrace ? Can you try the patch from this thread to show what memory the offender tries to access ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
> Le 16.02.2008 09:25, Andrew Morton a écrit :
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
>
> Got this in dmesg output:
>
> [ cut here ]
> WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40
> [] warn_on_slowpath+0x41/0x6d
> [] ? trace_hardirqs_on+0xb/0xd
> [] ? acpi_os_release_object+0x8/0xc
> [] ? acpi_ut_delete_object_desc+0x39/0x3e
> [] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9
> [] ? trace_hardirqs_on+0xb/0xd
> [] ? trace_hardirqs_on_caller+0xdf/0x100
> [] ? trace_hardirqs_on+0xb/0xd
> [] __ioremap+0xc7/0x182
> [] ioremap_nocache+0xa/0xc
> [] acpi_os_map_memory+0x11/0x1a
> [] acpi_ex_system_memory_space_handler+0xd3/0x228
> [] ? acpi_ev_address_space_dispatch+0x142/0x1a8
> [] ? acpi_ex_system_memory_space_handler+0x0/0x228
> [] acpi_ev_address_space_dispatch+0x167/0x1a8
> [] acpi_ex_access_region+0x1e4/0x270
> [] acpi_ex_field_datum_io+0x153/0x2a1
> [] ? cache_alloc_debugcheck_after+0xe9/0x165
> [] acpi_ex_extract_from_field+0x91/0x224
> [] ? acpi_ex_read_data_from_field+0x163/0x1b0
> [] acpi_ex_read_data_from_field+0x180/0x1b0
> [] acpi_ex_resolve_node_to_value+0x1aa/0x230
> [] acpi_ex_resolve_to_value+0x270/0x2aa
> [] acpi_ex_resolve_operands+0x24e/0x52f
> [] acpi_ds_exec_end_op+0xb7/0x4f4
> [] acpi_ps_parse_loop+0x5e5/0x79c
> [] acpi_ps_parse_aml+0xb2/0x2dd
> [] acpi_ps_execute_method+0x13d/0x20d
> [] acpi_ns_evaluate+0x10e/0x1b0
> [] acpi_ut_evaluate_object+0x57/0x1a1
> [] acpi_ut_execute_STA+0x22/0x7b
> [] ? acpi_ut_release_mutex+0x85/0x8f
> [] acpi_ns_get_device_callback+0x5a/0x121
> [] acpi_ns_walk_namespace+0xfa/0x114
> [] acpi_get_devices+0x47/0x5d
> [] ? acpi_ns_get_device_callback+0x0/0x121
> [] ? ec_parse_device+0x0/0x6e
> [] acpi_ec_ecdt_probe+0xaa/0x10a
> [] acpi_init+0x73/0x21e
> [] ? class_create+0x4b/0x64
> [] kernel_init+0xa3/0x1f3
> [] ? restore_nocheck_notrace+0x0/0xe
> [] ? kernel_init+0x0/0x1f3
> [] ? kernel_init+0x0/0x1f3
> [] kernel_thread_helper+0x7/0x10
> ===
> ---[ end trace 4eaa2a86a8e2da22 ]---
>
> The offending code in arch/x86/mm/ioremap.c is:
> 101 static void __iomem *__ioremap(unsigned long phys_addr, unsigned long
> size,
> 102enum ioremap_mode mode)
> 103 {
> ...
> 119 /*
> 120 * Don't allow anybody to remap normal RAM that we're using..
> 121 */
> 122 for (pfn = phys_addr >> PAGE_SHIFT; pfn < max_pfn_mapped &&
> 123 (pfn << PAGE_SHIFT) < last_addr; pfn++) {
> 124 if (page_is_ram(pfn) && pfn_valid(pfn) &&
> 125 !PageReserved(pfn_to_page(pfn)))
> 126 return NULL;
> 127 }
> 128
> 129 WARN_ON_ONCE(page_is_ram(pfn));
> 130
>
> The WARN_ON was introduced by git-agpgart.patch.
>
[..]
I'm getting that in mainline now on one of my older laptops also.
> laurent
>
Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
Got this in dmesg output:
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40
[c0118955] warn_on_slowpath+0x41/0x6d
[c0131d0a] ? trace_hardirqs_on+0xb/0xd
[c01fdd89] ? acpi_os_release_object+0x8/0xc
[c02188d4] ? acpi_ut_delete_object_desc+0x39/0x3e
[c0217f05] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9
[c0131d0a] ? trace_hardirqs_on+0xb/0xd
[c0131cde] ? trace_hardirqs_on_caller+0xdf/0x100
[c0131d0a] ? trace_hardirqs_on+0xb/0xd
[c01129c5] __ioremap+0xc7/0x182
[c0112a99] ioremap_nocache+0xa/0xc
[c02a6877] acpi_os_map_memory+0x11/0x1a
[c020b697] acpi_ex_system_memory_space_handler+0xd3/0x228
[c0203bd8] ? acpi_ev_address_space_dispatch+0x142/0x1a8
[c020b5c4] ? acpi_ex_system_memory_space_handler+0x0/0x228
[c0203bfd] acpi_ev_address_space_dispatch+0x167/0x1a8
[c02083dd] acpi_ex_access_region+0x1e4/0x270
[c02085bc] acpi_ex_field_datum_io+0x153/0x2a1
[c0158ac0] ? cache_alloc_debugcheck_after+0xe9/0x165
[c020879b] acpi_ex_extract_from_field+0x91/0x224
[c0206bcf] ? acpi_ex_read_data_from_field+0x163/0x1b0
[c0206bec] acpi_ex_read_data_from_field+0x180/0x1b0
[c020d256] acpi_ex_resolve_node_to_value+0x1aa/0x230
[c0207a32] acpi_ex_resolve_to_value+0x270/0x2aa
[c0209e47] acpi_ex_resolve_operands+0x24e/0x52f
[c0200827] acpi_ds_exec_end_op+0xb7/0x4f4
[c0212d51] acpi_ps_parse_loop+0x5e5/0x79c
[c02120dc] acpi_ps_parse_aml+0xb2/0x2dd
[c021350c] acpi_ps_execute_method+0x13d/0x20d
[c020fb72] acpi_ns_evaluate+0x10e/0x1b0
[c02164ca] acpi_ut_evaluate_object+0x57/0x1a1
[c02166ce] acpi_ut_execute_STA+0x22/0x7b
[c0218d61] ? acpi_ut_release_mutex+0x85/0x8f
[c020f45d] acpi_ns_get_device_callback+0x5a/0x121
[c021173e] acpi_ns_walk_namespace+0xfa/0x114
[c020f381] acpi_get_devices+0x47/0x5d
[c020f403] ? acpi_ns_get_device_callback+0x0/0x121
[c021ce4a] ? ec_parse_device+0x0/0x6e
[c03a4460] acpi_ec_ecdt_probe+0xaa/0x10a
[c03a404b] acpi_init+0x73/0x21e
[c023e5bb] ? class_create+0x4b/0x64
[c0390652] kernel_init+0xa3/0x1f3
[c0103a4e] ? restore_nocheck_notrace+0x0/0xe
[c03905af] ? kernel_init+0x0/0x1f3
[c03905af] ? kernel_init+0x0/0x1f3
[c01045a7] kernel_thread_helper+0x7/0x10
===
---[ end trace 4eaa2a86a8e2da22 ]---
The offending code in arch/x86/mm/ioremap.c is:
101 static void __iomem *__ioremap(unsigned long phys_addr, unsigned long
size,
102enum ioremap_mode mode)
103 {
...
119 /*
120 * Don't allow anybody to remap normal RAM that we're using..
121 */
122 for (pfn = phys_addr PAGE_SHIFT; pfn max_pfn_mapped
123 (pfn PAGE_SHIFT) last_addr; pfn++) {
124 if (page_is_ram(pfn) pfn_valid(pfn)
125 !PageReserved(pfn_to_page(pfn)))
126 return NULL;
127 }
128
129 WARN_ON_ONCE(page_is_ram(pfn));
130
The WARN_ON was introduced by git-agpgart.patch.
[..]
I'm getting that in mainline now on one of my older laptops also.
laurent
Gabriel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Gabriel C wrote: Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ [..] I'm getting that in mainline now on one of my older laptops also. we fixed the cause of the machine you quoted; so I suspect yours is different.. Can you get me your stacktrace ? Can you try the patch from this thread to show what memory the offender tries to access ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote: ioremap: trying to map RAM page at 0 <=== Completing Region/Field/Buffer/Package initialization: Hope this helps. actually... it helps a lot. I'll cook up a patch for this now :) thanks for testing so quickly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Le 18.02.2008 20:35, Arjan van de Ven a écrit : Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ Got this in dmesg output: [ cut here ] WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182() Can you try the patch below? It should print a bit more information so that we can figure out who's really at fault here.. (eg it's either the diagnostics that are wrong, or ACPI is doing something evil (on behalf of the bios), we need to know what address is being triggered) I've got 2 new lines in dmesg output: ACPI: EC: Look up EC in DSDT ioremap: trying to map RAM page at 0 <=== [ cut here ] WARNING: at arch/x86/mm/ioremap.c:134 __ioremap+0xe8/0x1b6() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #41 [] warn_on_slowpath+0x41/0x6d [] ? trace_hardirqs_off+0xb/0xd [] ? runqueue_is_locked+0x23/0x3f [] ? release_console_sem+0x1be/0x1c6 [] ? vprintk+0x2d0/0x31d [] __ioremap+0xe8/0x1b6 [] ioremap_nocache+0xa/0xc [] acpi_os_map_memory+0x11/0x1a [] acpi_ex_system_memory_space_handler+0xd3/0x228 [] ? acpi_ev_address_space_dispatch+0x142/0x1a8 [] ? acpi_ex_system_memory_space_handler+0x0/0x228 [] acpi_ev_address_space_dispatch+0x167/0x1a8 [] acpi_ex_access_region+0x1e4/0x270 [] acpi_ex_field_datum_io+0x153/0x2a1 [] ? cache_alloc_debugcheck_after+0xe9/0x165 [] acpi_ex_extract_from_field+0x91/0x224 [] ? acpi_ex_read_data_from_field+0x163/0x1b0 [] acpi_ex_read_data_from_field+0x180/0x1b0 [] acpi_ex_resolve_node_to_value+0x1aa/0x230 [] acpi_ex_resolve_to_value+0x270/0x2aa [] acpi_ex_resolve_operands+0x24e/0x52f [] acpi_ds_exec_end_op+0xb7/0x4f4 [] acpi_ps_parse_loop+0x5e5/0x79c [] acpi_ps_parse_aml+0xb2/0x2dd [] acpi_ps_execute_method+0x13d/0x20d [] acpi_ns_evaluate+0x10e/0x1b0 [] acpi_ut_evaluate_object+0x57/0x1a1 [] acpi_ut_execute_STA+0x22/0x7b [] ? acpi_ut_release_mutex+0x85/0x8f [] acpi_ns_get_device_callback+0x5a/0x121 [] acpi_ns_walk_namespace+0xfa/0x114 [] acpi_get_devices+0x47/0x5d [] ? acpi_ns_get_device_callback+0x0/0x121 [] ? ec_parse_device+0x0/0x6e [] acpi_ec_ecdt_probe+0xaa/0x10a [] acpi_init+0x73/0x21e [] ? class_create+0x4b/0x64 [] kernel_init+0xa3/0x1f3 [] ? restore_nocheck_notrace+0x0/0xe [] ? kernel_init+0x0/0x1f3 [] ? kernel_init+0x0/0x1f3 [] kernel_thread_helper+0x7/0x10 === ---[ end trace 4eaa2a86a8e2da22 ]--- ioremap: trying to map RAM page at 0 <=== Completing Region/Field/Buffer/Package initialization: Hope this helps. -- laurent -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
Got this in dmesg output:
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
Can you try the patch below? It should print a bit more information so that we
can
figure out who's really at fault here.. (eg it's either the diagnostics that are
wrong, or ACPI is doing something evil (on behalf of the bios), we need to know
what address is being triggered)
From c346400b372a99a4158fce3ea45234bcf947bdf8 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Mon, 18 Feb 2008 08:01:47 -0800
Subject: [PATCH] More diagnostic output for the ioremap WARN_ON
now that ACPI seems to have triggered this WARN_ON.. we need to know
which address it triggers on to be able to judge a final "who's at fault".
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/mm/ioremap.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 69f4981..524dd45 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -126,7 +126,15 @@ static void __iomem *__ioremap(unsigned long phys_addr,
unsigned long size,
return NULL;
}
- WARN_ON_ONCE(page_is_ram(pfn));
+ for (pfn = phys_addr >> PAGE_SHIFT; pfn < max_pfn_mapped &&
+(pfn << PAGE_SHIFT) < last_addr; pfn++) {
+ if (page_is_ram(pfn)) {
+ printk(KERN_ERR "ioremap: trying to map RAM page at
%lx\n",
+ pfn << PAGE_SHIFT);
+ WARN_ON_ONCE(page_is_ram(pfn));
+ }
+ }
+
switch (mode) {
case IOR_MODE_UNCACHED:
--
1.5.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
Got this in dmesg output:
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
Can you try the patch below? It should print a bit more information so that we
can
figure out who's really at fault here.. (eg it's either the diagnostics that are
wrong, or ACPI is doing something evil (on behalf of the bios), we need to know
what address is being triggered)
From c346400b372a99a4158fce3ea45234bcf947bdf8 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven [EMAIL PROTECTED]
Date: Mon, 18 Feb 2008 08:01:47 -0800
Subject: [PATCH] More diagnostic output for the ioremap WARN_ON
now that ACPI seems to have triggered this WARN_ON.. we need to know
which address it triggers on to be able to judge a final who's at fault.
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
arch/x86/mm/ioremap.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 69f4981..524dd45 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -126,7 +126,15 @@ static void __iomem *__ioremap(unsigned long phys_addr,
unsigned long size,
return NULL;
}
- WARN_ON_ONCE(page_is_ram(pfn));
+ for (pfn = phys_addr PAGE_SHIFT; pfn max_pfn_mapped
+(pfn PAGE_SHIFT) last_addr; pfn++) {
+ if (page_is_ram(pfn)) {
+ printk(KERN_ERR ioremap: trying to map RAM page at
%lx\n,
+ pfn PAGE_SHIFT);
+ WARN_ON_ONCE(page_is_ram(pfn));
+ }
+ }
+
switch (mode) {
case IOR_MODE_UNCACHED:
--
1.5.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Le 18.02.2008 20:35, Arjan van de Ven a écrit : Laurent Riffard wrote: Le 16.02.2008 09:25, Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ Got this in dmesg output: [ cut here ] WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182() Can you try the patch below? It should print a bit more information so that we can figure out who's really at fault here.. (eg it's either the diagnostics that are wrong, or ACPI is doing something evil (on behalf of the bios), we need to know what address is being triggered) I've got 2 new lines in dmesg output: ACPI: EC: Look up EC in DSDT ioremap: trying to map RAM page at 0 === [ cut here ] WARNING: at arch/x86/mm/ioremap.c:134 __ioremap+0xe8/0x1b6() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #41 [c0118989] warn_on_slowpath+0x41/0x6d [c0130ae6] ? trace_hardirqs_off+0xb/0xd [c0116326] ? runqueue_is_locked+0x23/0x3f [c0118d31] ? release_console_sem+0x1be/0x1c6 [c0119304] ? vprintk+0x2d0/0x31d [c01129e6] __ioremap+0xe8/0x1b6 [c0112acd] ioremap_nocache+0xa/0xc [c02a68a7] acpi_os_map_memory+0x11/0x1a [c020b6c7] acpi_ex_system_memory_space_handler+0xd3/0x228 [c0203c08] ? acpi_ev_address_space_dispatch+0x142/0x1a8 [c020b5f4] ? acpi_ex_system_memory_space_handler+0x0/0x228 [c0203c2d] acpi_ev_address_space_dispatch+0x167/0x1a8 [c020840d] acpi_ex_access_region+0x1e4/0x270 [c02085ec] acpi_ex_field_datum_io+0x153/0x2a1 [c0158af4] ? cache_alloc_debugcheck_after+0xe9/0x165 [c02087cb] acpi_ex_extract_from_field+0x91/0x224 [c0206bff] ? acpi_ex_read_data_from_field+0x163/0x1b0 [c0206c1c] acpi_ex_read_data_from_field+0x180/0x1b0 [c020d286] acpi_ex_resolve_node_to_value+0x1aa/0x230 [c0207a62] acpi_ex_resolve_to_value+0x270/0x2aa [c0209e77] acpi_ex_resolve_operands+0x24e/0x52f [c0200857] acpi_ds_exec_end_op+0xb7/0x4f4 [c0212d81] acpi_ps_parse_loop+0x5e5/0x79c [c021210c] acpi_ps_parse_aml+0xb2/0x2dd [c021353c] acpi_ps_execute_method+0x13d/0x20d [c020fba2] acpi_ns_evaluate+0x10e/0x1b0 [c02164fa] acpi_ut_evaluate_object+0x57/0x1a1 [c02166fe] acpi_ut_execute_STA+0x22/0x7b [c0218d91] ? acpi_ut_release_mutex+0x85/0x8f [c020f48d] acpi_ns_get_device_callback+0x5a/0x121 [c021176e] acpi_ns_walk_namespace+0xfa/0x114 [c020f3b1] acpi_get_devices+0x47/0x5d [c020f433] ? acpi_ns_get_device_callback+0x0/0x121 [c021ce7a] ? ec_parse_device+0x0/0x6e [c03a4460] acpi_ec_ecdt_probe+0xaa/0x10a [c03a404b] acpi_init+0x73/0x21e [c023e5eb] ? class_create+0x4b/0x64 [c0390652] kernel_init+0xa3/0x1f3 [c0103a4e] ? restore_nocheck_notrace+0x0/0xe [c03905af] ? kernel_init+0x0/0x1f3 [c03905af] ? kernel_init+0x0/0x1f3 [c01045a7] kernel_thread_helper+0x7/0x10 === ---[ end trace 4eaa2a86a8e2da22 ]--- ioremap: trying to map RAM page at 0 === Completing Region/Field/Buffer/Package initialization: Hope this helps. -- laurent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote: ioremap: trying to map RAM page at 0 === Completing Region/Field/Buffer/Package initialization: Hope this helps. actually... it helps a lot. I'll cook up a patch for this now :) thanks for testing so quickly -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
On Sun, 17 Feb 2008 23:58:03 -0500 "Brown, Len" <[EMAIL PROTECTED]> wrote: > >Len: This WARN_ON says that ACPI is trying to call ioremap() > >on memory that the e820_table > >lists as "kernel owned". Do you know why ACPI would do this? > >Would ACPI get upset if > >the kernel would tell it to take a hike? > > Depends on the BIOS -- as it is the BIOS AML that is making this > request. is there any possible valid scenario where the BIOS AML would touch memory the kernel is using? (Since that seems to be what is going on; I'll cook up a diagnostics patch to get more info but the warning gets spewed if ioremap() is trying to map memory the kernel sees as ram) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
>> evxfevnt-0091 [00] enable: Transition to >ACPI mode successful >> khelper used greatest stack depth: 3144 bytes left >> net_namespace: 304 bytes >> NET: Registered protocol family 16 >> ACPI: bus type pci registered >> khelper used greatest stack depth: 3032 bytes left >> PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 >> PCI: Using configuration type 1 >> Setting up standard PCI resources >> evgpeblk-0956 [00] ev_create_gpe_block : GPE 00 to 0F >[_GPE] 2 regs on int 0x9 >> evgpeblk-1052 [00] ev_initialize_gpe_bloc: Found 4 Wake, >Enabled 0 Runtime GPEs in this block >> ACPI: EC: Look up EC in DSDT >> [ cut here ] >> WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182() >> Modules linked in: >> Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40 >> [] warn_on_slowpath+0x41/0x6d >> [] ? trace_hardirqs_on+0xb/0xd >> [] ? acpi_os_release_object+0x8/0xc >> [] ? acpi_ut_delete_object_desc+0x39/0x3e >> [] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9 >> [] ? trace_hardirqs_on+0xb/0xd >> [] ? trace_hardirqs_on_caller+0xdf/0x100 >> [] ? trace_hardirqs_on+0xb/0xd >> [] __ioremap+0xc7/0x182 >> [] ioremap_nocache+0xa/0xc >> [] acpi_os_map_memory+0x11/0x1a >> [] acpi_ex_system_memory_space_handler+0xd3/0x228 >> [] ? acpi_ev_address_space_dispatch+0x142/0x1a8 >> [] ? acpi_ex_system_memory_space_handler+0x0/0x228 >> [] acpi_ev_address_space_dispatch+0x167/0x1a8 >> [] acpi_ex_access_region+0x1e4/0x270 >> [] acpi_ex_field_datum_io+0x153/0x2a1 >> [] ? cache_alloc_debugcheck_after+0xe9/0x165 >> [] acpi_ex_extract_from_field+0x91/0x224 >> [] ? acpi_ex_read_data_from_field+0x163/0x1b0 >> [] acpi_ex_read_data_from_field+0x180/0x1b0 >> [] acpi_ex_resolve_node_to_value+0x1aa/0x230 >> [] acpi_ex_resolve_to_value+0x270/0x2aa >> [] acpi_ex_resolve_operands+0x24e/0x52f > >Len: This WARN_ON says that ACPI is trying to call ioremap() >on memory that the e820_table >lists as "kernel owned". Do you know why ACPI would do this? >Would ACPI get upset if >the kernel would tell it to take a hike? Depends on the BIOS -- as it is the BIOS AML that is making this request. -Len -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
evxfevnt-0091 [00] enable: Transition to ACPI mode successful khelper used greatest stack depth: 3144 bytes left net_namespace: 304 bytes NET: Registered protocol family 16 ACPI: bus type pci registered khelper used greatest stack depth: 3032 bytes left PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources evgpeblk-0956 [00] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9 evgpeblk-1052 [00] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block ACPI: EC: Look up EC in DSDT [ cut here ] WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182() Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40 [c0118955] warn_on_slowpath+0x41/0x6d [c0131d0a] ? trace_hardirqs_on+0xb/0xd [c01fdd89] ? acpi_os_release_object+0x8/0xc [c02188d4] ? acpi_ut_delete_object_desc+0x39/0x3e [c0217f05] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9 [c0131d0a] ? trace_hardirqs_on+0xb/0xd [c0131cde] ? trace_hardirqs_on_caller+0xdf/0x100 [c0131d0a] ? trace_hardirqs_on+0xb/0xd [c01129c5] __ioremap+0xc7/0x182 [c0112a99] ioremap_nocache+0xa/0xc [c02a6877] acpi_os_map_memory+0x11/0x1a [c020b697] acpi_ex_system_memory_space_handler+0xd3/0x228 [c0203bd8] ? acpi_ev_address_space_dispatch+0x142/0x1a8 [c020b5c4] ? acpi_ex_system_memory_space_handler+0x0/0x228 [c0203bfd] acpi_ev_address_space_dispatch+0x167/0x1a8 [c02083dd] acpi_ex_access_region+0x1e4/0x270 [c02085bc] acpi_ex_field_datum_io+0x153/0x2a1 [c0158ac0] ? cache_alloc_debugcheck_after+0xe9/0x165 [c020879b] acpi_ex_extract_from_field+0x91/0x224 [c0206bcf] ? acpi_ex_read_data_from_field+0x163/0x1b0 [c0206bec] acpi_ex_read_data_from_field+0x180/0x1b0 [c020d256] acpi_ex_resolve_node_to_value+0x1aa/0x230 [c0207a32] acpi_ex_resolve_to_value+0x270/0x2aa [c0209e47] acpi_ex_resolve_operands+0x24e/0x52f Len: This WARN_ON says that ACPI is trying to call ioremap() on memory that the e820_table lists as kernel owned. Do you know why ACPI would do this? Would ACPI get upset if the kernel would tell it to take a hike? Depends on the BIOS -- as it is the BIOS AML that is making this request. -Len -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
On Sun, 17 Feb 2008 23:58:03 -0500 Brown, Len [EMAIL PROTECTED] wrote: Len: This WARN_ON says that ACPI is trying to call ioremap() on memory that the e820_table lists as kernel owned. Do you know why ACPI would do this? Would ACPI get upset if the kernel would tell it to take a hike? Depends on the BIOS -- as it is the BIOS AML that is making this request. is there any possible valid scenario where the BIOS AML would touch memory the kernel is using? (Since that seems to be what is going on; I'll cook up a diagnostics patch to get more info but the warning gets spewed if ioremap() is trying to map memory the kernel sees as ram) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
Got this in dmesg output:
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40
[] warn_on_slowpath+0x41/0x6d
[] ? trace_hardirqs_on+0xb/0xd
[] ? acpi_os_release_object+0x8/0xc
[] ? acpi_ut_delete_object_desc+0x39/0x3e
[] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9
[] ? trace_hardirqs_on+0xb/0xd
[] ? trace_hardirqs_on_caller+0xdf/0x100
[] ? trace_hardirqs_on+0xb/0xd
[] __ioremap+0xc7/0x182
[] ioremap_nocache+0xa/0xc
[] acpi_os_map_memory+0x11/0x1a
[] acpi_ex_system_memory_space_handler+0xd3/0x228
[] ? acpi_ev_address_space_dispatch+0x142/0x1a8
[] ? acpi_ex_system_memory_space_handler+0x0/0x228
[] acpi_ev_address_space_dispatch+0x167/0x1a8
[] acpi_ex_access_region+0x1e4/0x270
[] acpi_ex_field_datum_io+0x153/0x2a1
[] ? cache_alloc_debugcheck_after+0xe9/0x165
[] acpi_ex_extract_from_field+0x91/0x224
[] ? acpi_ex_read_data_from_field+0x163/0x1b0
[] acpi_ex_read_data_from_field+0x180/0x1b0
[] acpi_ex_resolve_node_to_value+0x1aa/0x230
[] acpi_ex_resolve_to_value+0x270/0x2aa
[] acpi_ex_resolve_operands+0x24e/0x52f
[] acpi_ds_exec_end_op+0xb7/0x4f4
[] acpi_ps_parse_loop+0x5e5/0x79c
[] acpi_ps_parse_aml+0xb2/0x2dd
[] acpi_ps_execute_method+0x13d/0x20d
[] acpi_ns_evaluate+0x10e/0x1b0
[] acpi_ut_evaluate_object+0x57/0x1a1
[] acpi_ut_execute_STA+0x22/0x7b
[] ? acpi_ut_release_mutex+0x85/0x8f
[] acpi_ns_get_device_callback+0x5a/0x121
[] acpi_ns_walk_namespace+0xfa/0x114
[] acpi_get_devices+0x47/0x5d
[] ? acpi_ns_get_device_callback+0x0/0x121
[] ? ec_parse_device+0x0/0x6e
[] acpi_ec_ecdt_probe+0xaa/0x10a
[] acpi_init+0x73/0x21e
[] ? class_create+0x4b/0x64
[] kernel_init+0xa3/0x1f3
[] ? restore_nocheck_notrace+0x0/0xe
[] ? kernel_init+0x0/0x1f3
[] ? kernel_init+0x0/0x1f3
[] kernel_thread_helper+0x7/0x10
===
---[ end trace 4eaa2a86a8e2da22 ]---
The offending code in arch/x86/mm/ioremap.c is:
101 static void __iomem *__ioremap(unsigned long phys_addr, unsigned
long size,
102enum ioremap_mode mode)
103 {
...
119 /*
120 * Don't allow anybody to remap normal RAM that we're using..
121 */
122 for (pfn = phys_addr >> PAGE_SHIFT; pfn < max_pfn_mapped &&
123 (pfn << PAGE_SHIFT) < last_addr; pfn++) {
124 if (page_is_ram(pfn) && pfn_valid(pfn) &&
125 !PageReserved(pfn_to_page(pfn)))
126 return NULL;
127 }
128 129 WARN_ON_ONCE(page_is_ram(pfn));
130
The WARN_ON was introduced by git-agpgart.patch.
CC'd Stuart Bennett and Arjan van dev Ven.
attached: full dmesg and config.
~~
laurent
Linux version 2.6.25-rc2-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)) #40 PREEMPT Sat Feb 16 21:34:19 CET 2008
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 1ffec000 (usable)
BIOS-e820: 1ffec000 - 1ffef000 (ACPI data)
BIOS-e820: 1ffef000 - 1000 (reserved)
BIOS-e820: 1000 - 2000 (ACPI NVS)
BIOS-e820: - 0001 (reserved)
511MB LOWMEM available.
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Entering add_active_range(0, 0, 131052) 0 entries of 256 used
sizeof(struct page) = 32
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 131052
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 -> 131052
On node 0 totalpages: 131052
Node 0 memmap at 0xc100 size 4194304 first pfn 0xc100
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 991 pages used for memmap
Normal zone: 125965 pages, LIFO batch:31
Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000F6A80, 0014 (r0 ASUS )
ACPI: RSDT 1FFEC000, 002C (r1 ASUS A7V133-C 30303031 MSFT 31313031)
ACPI: FACP 1FFEC080, 0074 (r1 ASUS A7V133-C 30303031 MSFT 31313031)
ACPI: DSDT 1FFEC100, 2CE1 (r1 ASUS A7V133-C 1000 MSFT 10B)
ACPI: FACS 1000, 0040
ACPI: BOOT 1FFEC040, 0028 (r1 ASUS A7V133-C 30303031 MSFT 31313031)
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 3000 (gap: 2000:dfff)
PM: Registered nosave memory: 0009f000 - 000a
PM: Registered nosave memory: 000a - 000f
PM: Registered nosave memory:
Re: 2.6.25-rc2-mm1: WARNING at arch/x86/mm/ioremap.c:129
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
Got this in dmesg output:
[ cut here ]
WARNING: at arch/x86/mm/ioremap.c:129 __ioremap+0xc7/0x182()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #40
[c0118955] warn_on_slowpath+0x41/0x6d
[c0131d0a] ? trace_hardirqs_on+0xb/0xd
[c01fdd89] ? acpi_os_release_object+0x8/0xc
[c02188d4] ? acpi_ut_delete_object_desc+0x39/0x3e
[c0217f05] ? acpi_ut_delete_internal_obj+0x2c1/0x2c9
[c0131d0a] ? trace_hardirqs_on+0xb/0xd
[c0131cde] ? trace_hardirqs_on_caller+0xdf/0x100
[c0131d0a] ? trace_hardirqs_on+0xb/0xd
[c01129c5] __ioremap+0xc7/0x182
[c0112a99] ioremap_nocache+0xa/0xc
[c02a6877] acpi_os_map_memory+0x11/0x1a
[c020b697] acpi_ex_system_memory_space_handler+0xd3/0x228
[c0203bd8] ? acpi_ev_address_space_dispatch+0x142/0x1a8
[c020b5c4] ? acpi_ex_system_memory_space_handler+0x0/0x228
[c0203bfd] acpi_ev_address_space_dispatch+0x167/0x1a8
[c02083dd] acpi_ex_access_region+0x1e4/0x270
[c02085bc] acpi_ex_field_datum_io+0x153/0x2a1
[c0158ac0] ? cache_alloc_debugcheck_after+0xe9/0x165
[c020879b] acpi_ex_extract_from_field+0x91/0x224
[c0206bcf] ? acpi_ex_read_data_from_field+0x163/0x1b0
[c0206bec] acpi_ex_read_data_from_field+0x180/0x1b0
[c020d256] acpi_ex_resolve_node_to_value+0x1aa/0x230
[c0207a32] acpi_ex_resolve_to_value+0x270/0x2aa
[c0209e47] acpi_ex_resolve_operands+0x24e/0x52f
[c0200827] acpi_ds_exec_end_op+0xb7/0x4f4
[c0212d51] acpi_ps_parse_loop+0x5e5/0x79c
[c02120dc] acpi_ps_parse_aml+0xb2/0x2dd
[c021350c] acpi_ps_execute_method+0x13d/0x20d
[c020fb72] acpi_ns_evaluate+0x10e/0x1b0
[c02164ca] acpi_ut_evaluate_object+0x57/0x1a1
[c02166ce] acpi_ut_execute_STA+0x22/0x7b
[c0218d61] ? acpi_ut_release_mutex+0x85/0x8f
[c020f45d] acpi_ns_get_device_callback+0x5a/0x121
[c021173e] acpi_ns_walk_namespace+0xfa/0x114
[c020f381] acpi_get_devices+0x47/0x5d
[c020f403] ? acpi_ns_get_device_callback+0x0/0x121
[c021ce4a] ? ec_parse_device+0x0/0x6e
[c03a4460] acpi_ec_ecdt_probe+0xaa/0x10a
[c03a404b] acpi_init+0x73/0x21e
[c023e5bb] ? class_create+0x4b/0x64
[c0390652] kernel_init+0xa3/0x1f3
[c0103a4e] ? restore_nocheck_notrace+0x0/0xe
[c03905af] ? kernel_init+0x0/0x1f3
[c03905af] ? kernel_init+0x0/0x1f3
[c01045a7] kernel_thread_helper+0x7/0x10
===
---[ end trace 4eaa2a86a8e2da22 ]---
The offending code in arch/x86/mm/ioremap.c is:
101 static void __iomem *__ioremap(unsigned long phys_addr, unsigned
long size,
102enum ioremap_mode mode)
103 {
...
119 /*
120 * Don't allow anybody to remap normal RAM that we're using..
121 */
122 for (pfn = phys_addr PAGE_SHIFT; pfn max_pfn_mapped
123 (pfn PAGE_SHIFT) last_addr; pfn++) {
124 if (page_is_ram(pfn) pfn_valid(pfn)
125 !PageReserved(pfn_to_page(pfn)))
126 return NULL;
127 }
128 129 WARN_ON_ONCE(page_is_ram(pfn));
130
The WARN_ON was introduced by git-agpgart.patch.
CC'd Stuart Bennett and Arjan van dev Ven.
attached: full dmesg and config.
~~
laurent
Linux version 2.6.25-rc2-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)) #40 PREEMPT Sat Feb 16 21:34:19 CET 2008
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 1ffec000 (usable)
BIOS-e820: 1ffec000 - 1ffef000 (ACPI data)
BIOS-e820: 1ffef000 - 1000 (reserved)
BIOS-e820: 1000 - 2000 (ACPI NVS)
BIOS-e820: - 0001 (reserved)
511MB LOWMEM available.
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Entering add_active_range(0, 0, 131052) 0 entries of 256 used
sizeof(struct page) = 32
Zone PFN ranges:
DMA 0 - 4096
Normal 4096 - 131052
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 - 131052
On node 0 totalpages: 131052
Node 0 memmap at 0xc100 size 4194304 first pfn 0xc100
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 991 pages used for memmap
Normal zone: 125965 pages, LIFO batch:31
Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000F6A80, 0014 (r0 ASUS )
ACPI: RSDT 1FFEC000, 002C (r1 ASUS A7V133-C 30303031 MSFT 31313031)
ACPI: FACP 1FFEC080, 0074 (r1 ASUS A7V133-C 30303031 MSFT 31313031)
ACPI: DSDT 1FFEC100, 2CE1 (r1 ASUS A7V133-C 1000 MSFT 10B)
ACPI: FACS 1000, 0040
