Description of problem: Seeing kernel failure on two machines on boot up (warning) with kernel-2.6.28.1-11.fc10.i686 Machine 1: Kernel failure message 1: ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:227 __ioremap_caller+0x57/0x213() (Not tainted) Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.28.1-11.fc10.i686 #1 Call Trace: Machine 2: Kernel failure message 1: ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:227 __ioremap_caller+0x57/0x213() (Not tainted) Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.28.1-11.fc10.i686 #1 Call Trace: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 329402 [details] cat /proc/iomem from Machine 1 cat /proc/iomem from Machine 1
Created attachment 329403 [details] cat /proc/iomem from Machine 2 cat /proc/iomem from Machine 2
Created attachment 329404 [details] lspci -vvnn from machine 1 lspci -vvnn from machine 1
Created attachment 329405 [details] lspci from machine 2 lspci from machine 2
One coincidence here. I have got this kernel on now 6 machines. Only two do this and are both are Pentium 4 2.8 GHz single threaded CPUs (no hyper threading). Considering the rest are dual core it can't be a coincidence.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1067588 Test patches backported from 2.6.29-rc1. cheers, Kyle
Hi Kyle. Both machines are ASUS motherboards as you suspected. Its unchanged still fails: Kernel failure message 1: ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:227 __ioremap_caller+0x57/0x213() (Not tainted) Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.28.1-15.bz480700.fc10.i686 #1 Call Trace:
Just to let you know 2.6.28.1-16 is the same. Let me know what you need. Thanks!
What does the line above "cut here" say? It should show the addresses that caused the warning.
Hi Chuck, That is the entire window that pops up. I 'showed' the message and copied the entire message to the clipboard. Its been forwarded to kerneloops also. I attached the dmesg here. Its still the same with 2.6.28.1-17 as well. Both machines are ASUS motherboards, and both are single thread 2.8GHz CPUs as well, so there has to be a connection.
Created attachment 329516 [details] dmesg output as log file dmesg output as log file
Created attachment 329517 [details] Screenshot off second machine showing that is all there is
Kyle suggested I try the F11 kernel that has the ASUS fix in it (rc2). I installed kernel-2.6.29-0.43.rc2.git1.fc11 No errors! Can this be back ported into F10 please?
Created attachment 329519 [details] dmesg from clean boot up and gnome login using the F11 kernel dmesg from clean boot up and gnome login using the F11 kernel
resource map sanity check conflict: 0x5fffff00 0x600000ff 0x5ffff000 0x5fffffff ACPI Non-volatile Storage ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:227 __ioremap_caller+0x57/0x213() (Not tainted)
So it appears to be this ASUS patch needed from F11 / Rawhide into 2.6.28 F10 kernels. Can this be ported into the F10 kernel as 2.6.28 will never make updates as everyone with ASUS motherboards will get this. I just tried 2.6.28.1-19 and its still the same. Please let me know anything you need. Can this bug be noted in the koji builds please, so I have an idea if its been addressed in the build. I will attach dmesg from BOTH machines failing on 2.6.28.1-19 Thanks!
Created attachment 329677 [details] dmesg from machine 1
Created attachment 329678 [details] dmesg from machine 2
Kyle, Your kernel-2.6.28.2-23.bz480700.fc10.src.rpm i686 fixed the issue! Many thanks for your efforts. Can we now get this patch into all future F10 builds and get a run of an updated 2.6.28.2-23.fc10.i686 or higher kernel? Cheers, David
Groovy, just fwiw this was the fix from upstream (nothing to do with asus at all after all :) commit 3ac52669c7a24b93663acfcab606d1065ed1accd Author: Arjan van de Ven <arjan.com> Date: Sat Dec 13 09:15:27 2008 -0800 resources: skip sanity check of busy resources Impact: reduce false positives in iomem_map_sanity_check() Some drivers (vesafb) only map/reserve a portion of a resource. If then some other driver comes in and maps the whole resource, the current code WARN_ON's. This is not the intent of the checks in iomem_map_sanity_check(); rather these checks want to warn when crossing *hardware* resources only. This patch skips BUSY resources as suggested by Linus. Note: having two drivers talk to the same hardware at the same time is obviously not optimal behavior, but that's a separate story. Signed-off-by: Arjan van de Ven <arjan.com> Signed-off-by: Ingo Molnar <mingo>