* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() [not found] <CADpTngUm7d88RJS9OV=64t6QrJU4r3M_Z8eV1QYWPeeB5SX5-w@mail.gmail.com> @ 2014-07-07 20:47 ` Greg Kroah-Hartman 2014-07-07 20:51 ` Fabio Coatti 2014-07-09 18:41 ` Fabio Coatti 0 siblings, 2 replies; 17+ messages in thread From: Greg Kroah-Hartman @ 2014-07-07 20:47 UTC (permalink / raw) To: Fabio Coatti; +Cc: linux-kernel On Mon, Jul 07, 2014 at 10:32:56PM +0200, Fabio Coatti wrote: > I'm seeing this message in latest kernels (this is from 3.15.4, but I have same > message starting from 3.15.0, IIRC): So 3.14.0 didn't show this? If so, can you run 'git bisect' between those two kernel versions to try to track down the issue? thanks, greg k-h ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-07 20:47 ` WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() Greg Kroah-Hartman @ 2014-07-07 20:51 ` Fabio Coatti 2014-07-09 18:41 ` Fabio Coatti 1 sibling, 0 replies; 17+ messages in thread From: Fabio Coatti @ 2014-07-07 20:51 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: linux-kernel In data lunedì 7 luglio 2014 13:47:47, Greg Kroah-Hartman ha scritto: > On Mon, Jul 07, 2014 at 10:32:56PM +0200, Fabio Coatti wrote: > > I'm seeing this message in latest kernels (this is from 3.15.4, but I have > > same > > message starting from 3.15.0, IIRC): > So 3.14.0 didn't show this? > > If so, can you run 'git bisect' between those two kernel versions to try > to track down the issue? > > thanks, > > greg k-h Yep, I'll do that, it will take some time as the last kernel not showing this message was 3.14.6 I'll keep you posted, thanks. -- Fabio ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-07 20:47 ` WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() Greg Kroah-Hartman 2014-07-07 20:51 ` Fabio Coatti @ 2014-07-09 18:41 ` Fabio Coatti 2014-07-09 18:54 ` Greg Kroah-Hartman 1 sibling, 1 reply; 17+ messages in thread From: Fabio Coatti @ 2014-07-09 18:41 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: linux-kernel In data lunedì 7 luglio 2014 13:47:47, Greg Kroah-Hartman ha scritto: > On Mon, Jul 07, 2014 at 10:32:56PM +0200, Fabio Coatti wrote: > > I'm seeing this message in latest kernels (this is from 3.15.4, but I have > > same > > message starting from 3.15.0, IIRC): > So 3.14.0 didn't show this? > > If so, can you run 'git bisect' between those two kernel versions to try > to track down the issue? > > thanks, > > greg k-h ok, I tried to bisect as suggested and got the commit reported below. However I'm not really sure to have got the right one, as one kernel refused to compile during the last steps. However I post here the result, maybe they can be useful. Tomorrow I can retry the whole process again starting from different commits. b9e1ab6d4c0582cad97699285a6b3cf992251b00 is the first bad commit commit b9e1ab6d4c0582cad97699285a6b3cf992251b00 Author: Stephane Eranian <eranian@google.com> Date: Tue Feb 11 16:20:12 2014 +0100 perf/x86/uncore: add SNB/IVB/HSW client uncore memory controller support This patch adds a new uncore PMU for Intel SNB/IVB/HSW client CPUs. It adds the Integrated Memory Controller (IMC) PMU. This new PMU provides a set of events to measure memory bandwidth utilization. The IMC on those processor is PCI-space based. This patch exposes a new uncore PMU on those processor: uncore_imc Two new events are defined: - name: data_reads - code: 0x1 - unit: 64 bytes - number of full cacheline read requests to the IMC - name: data_writes - code: 0x2 - unit: 64 bytes - number of full cacheline write requests to the IMC Documentation available at: http://software.intel.com/en-us/articles/monitoring-integrated-memory-controller-requests-in-the-2nd-3rd-and-4th-generation-intel Cc: mingo@elte.hu Cc: acme@redhat.com Cc: ak@linux.intel.com Cc: zheng.z.yan@intel.com Cc: peterz@infradead.org Signed-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1392132015-14521-7-git-send-email-eranian@google.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> :040000 040000 2d628022cbc4b8969a2ec311082053510cf6eed5 79b2a1cc3ed29e4820a5ae4221b4cf603c138887 M arch -- Fabio ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-09 18:41 ` Fabio Coatti @ 2014-07-09 18:54 ` Greg Kroah-Hartman 2014-07-09 19:48 ` Fabio Coatti 0 siblings, 1 reply; 17+ messages in thread From: Greg Kroah-Hartman @ 2014-07-09 18:54 UTC (permalink / raw) To: Fabio Coatti; +Cc: linux-kernel On Wed, Jul 09, 2014 at 08:41:17PM +0200, Fabio Coatti wrote: > In data lunedì 7 luglio 2014 13:47:47, Greg Kroah-Hartman ha scritto: > > On Mon, Jul 07, 2014 at 10:32:56PM +0200, Fabio Coatti wrote: > > > I'm seeing this message in latest kernels (this is from 3.15.4, but I have > > > same > > > message starting from 3.15.0, IIRC): > > So 3.14.0 didn't show this? > > > > If so, can you run 'git bisect' between those two kernel versions to try > > to track down the issue? > > > > thanks, > > > > greg k-h > ok, I tried to bisect as suggested and got the commit reported below. However > I'm not really sure to have got the right one, as one kernel refused to > compile during the last steps. However I post here the result, maybe they can > be useful. Try cc:ing everyone on that patch, with the original information you provided, and the linux-kernel mailing list. Those developers should be able to help you out properly. thanks, greg k-h ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-09 18:54 ` Greg Kroah-Hartman @ 2014-07-09 19:48 ` Fabio Coatti 2014-07-10 8:44 ` Peter Zijlstra 0 siblings, 1 reply; 17+ messages in thread From: Fabio Coatti @ 2014-07-09 19:48 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: linux-kernel, eranian, mingo, acme, ak, zheng.z.yan, peterz [-- Attachment #1: Type: text/plain, Size: 6693 bytes --] In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha scritto: > Try cc:ing everyone on that patch, with the original information you > provided, and the linux-kernel mailing list. Those developers should be > able to help you out properly. Ok, here you can find the description of a problem that I'm experiencing on latest kernels, since 3.15.0. (this report comes from 3.15.4) lug 07 22:08:00 calvin kernel: resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff reserved lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ lug 07 22:08:00 calvin kernel: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() lug 07 22:08:00 calvin kernel: Info: mapping multiple BARs. Your kernel is fine. lug 07 22:08:00 calvin kernel: Modules linked in: lug 07 22:08:00 calvin kernel: lug 07 22:08:00 calvin kernel: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.15.4 #1 lug 07 22:08:00 calvin kernel: Hardware name: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.40 02/01/2013 lug 07 22:08:00 calvin kernel: 00009f90000000f7 ffffffff8175d44b ffff8802334fbc78 ffffffff810af219 lug 07 22:08:00 calvin kernel: ffffffff81028e43 ffffc90000070000 ffff8802334fbcc8 00000000fed10000 lug 07 22:08:00 calvin kernel: 00000000fed16000 ffffffff810af275 ffffffff81991de2 0000000000000018 lug 07 22:08:00 calvin kernel: Call Trace: lug 07 22:08:00 calvin kernel: [<ffffffff8175d44b>] ? dump_stack+0x49/0x6a lug 07 22:08:00 calvin kernel: [<ffffffff810af219>] ? warn_slowpath_common+0x6f/0x84 lug 07 22:08:00 calvin kernel: [<ffffffff81028e43>] ? __ioremap_caller+0x290/0x2fa lug 07 22:08:00 calvin kernel: [<ffffffff810af275>] ? warn_slowpath_fmt+0x47/0x49 lug 07 22:08:00 calvin kernel: [<ffffffff810b3932>] ? iomem_map_sanity_check+0xa5/0xb1 lug 07 22:08:00 calvin kernel: [<ffffffff81028e43>] ? __ioremap_caller+0x290/0x2fa lug 07 22:08:00 calvin kernel: [<ffffffff81016316>] ? snb_uncore_imc_init_box+0x5c/0x7a lug 07 22:08:00 calvin kernel: [<ffffffff81017e8e>] ? uncore_pci_probe+0x100/0x168 lug 07 22:08:00 calvin kernel: [<ffffffff813c8da9>] ? pci_device_probe+0x6c/0xcb lug 07 22:08:00 calvin kernel: [<ffffffff814e8f46>] ? driver_probe_device+0x9b/0x1ce lug 07 22:08:00 calvin kernel: [<ffffffff814e90fd>] ? __driver_attach+0x53/0x73 lug 07 22:08:00 calvin kernel: [<ffffffff814e90aa>] ? __device_attach+0x31/0x31 lug 07 22:08:00 calvin kernel: [<ffffffff814e7814>] ? bus_for_each_dev+0x6e/0x78 lug 07 22:08:00 calvin kernel: [<ffffffff814e87f9>] ? bus_add_driver+0xfb/0x1c4 lug 07 22:08:00 calvin kernel: [<ffffffff814e95f9>] ? driver_register+0x83/0xbb lug 07 22:08:00 calvin kernel: [<ffffffff81cb0fb6>] ? uncore_pmu_register+0xd1/0xd1 lug 07 22:08:00 calvin kernel: [<ffffffff81cb1128>] ? intel_uncore_init+0x172/0x41e lug 07 22:08:00 calvin kernel: [<ffffffff81cb0fb6>] ? uncore_pmu_register+0xd1/0xd1 lug 07 22:08:00 calvin kernel: [<ffffffff8100029f>] ? do_one_initcall+0x88/0x11c lug 07 22:08:00 calvin kernel: [<ffffffff810c41ac>] ? parse_args+0x17f/0x23b lug 07 22:08:00 calvin kernel: [<ffffffff81ca8e1f>] ? kernel_init_freeable+0x14f/0x1d1 lug 07 22:08:00 calvin kernel: [<ffffffff81ca86b2>] ? do_early_param+0x81/0x81 lug 07 22:08:00 calvin kernel: [<ffffffff81756463>] ? rest_init+0x77/0x77 lug 07 22:08:00 calvin kernel: [<ffffffff81756468>] ? kernel_init+0x5/0xd0 lug 07 22:08:00 calvin kernel: [<ffffffff8176493c>] ? ret_from_fork+0x7c/0xb0 lug 07 22:08:00 calvin kernel: [<ffffffff81756463>] ? rest_init+0x77/0x77 lug 07 22:08:00 calvin kernel: ---[ end trace 076d7a33d4c45496 ]--- lug 07 22:08:00 calvin kernel: RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer Bisecting I got here: b9e1ab6d4c0582cad97699285a6b3cf992251b00 is the first bad commit commit b9e1ab6d4c0582cad97699285a6b3cf992251b00 Author: Stephane Eranian <eranian@google.com> Date: Tue Feb 11 16:20:12 2014 +0100 perf/x86/uncore: add SNB/IVB/HSW client uncore memory controller support This patch adds a new uncore PMU for Intel SNB/IVB/HSW client CPUs. It adds the Integrated Memory Controller (IMC) PMU. This new PMU provides a set of events to measure memory bandwidth utilization. The IMC on those processor is PCI-space based. This patch exposes a new uncore PMU on those processor: uncore_imc Two new events are defined: - name: data_reads - code: 0x1 - unit: 64 bytes - number of full cacheline read requests to the IMC - name: data_writes - code: 0x2 - unit: 64 bytes - number of full cacheline write requests to the IMC Documentation available at: http://software.intel.com/en-us/articles/monitoring-integrated-memory-controller-requests-in-the-2nd-3rd-and-4th-generation-intel Cc: mingo@elte.hu Cc: acme@redhat.com Cc: ak@linux.intel.com Cc: zheng.z.yan@intel.com Cc: peterz@infradead.org Signed-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1392132015-14521-7-git-send-email-eranian@google.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> :040000 040000 2d628022cbc4b8969a2ec311082053510cf6eed5 79b2a1cc3ed29e4820a5ae4221b4cf603c138887 M arch Please note that while bisecting I got a kernel with compilation error, so I'm not 100% sure of the correctness of the result. I can retry the whole process with differen starting point, however I send here the results hoping that they can be of some help. Attached you can find my config.gz gcc (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3 Linux calvin 3.15.4 #1 SMP PREEMPT Mon Jul 7 11:18:48 CEST 2014 x86_64 Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz GenuineIntel GNU/Linux Of course I'm available for any additional information, please cc: me as I'm not subscribed to lkml atm. many thanks. -- Fabio [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 23958 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-09 19:48 ` Fabio Coatti @ 2014-07-10 8:44 ` Peter Zijlstra 2014-07-10 8:52 ` Peter Zijlstra 0 siblings, 1 reply; 17+ messages in thread From: Peter Zijlstra @ 2014-07-10 8:44 UTC (permalink / raw) To: Fabio Coatti Cc: Greg Kroah-Hartman, linux-kernel, eranian, mingo, acme, ak, zheng.z.yan On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha scritto: > > > Try cc:ing everyone on that patch, with the original information you > > provided, and the linux-kernel mailing list. Those developers should be > > able to help you out properly. > > Ok, here you can find the description of a problem that I'm experiencing on > latest kernels, since 3.15.0. (this report comes from 3.15.4) > > lug 07 22:08:00 calvin kernel: resource map sanity check conflict: 0xfed10000 > 0xfed15fff 0xfed10000 0xfed13fff reserved > lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ I think this is a 'known' issue on Thinkpad (iirc). For some obscure reason its BIOS has funny ideas about resources etc. I couldn't quickly find the prvious thread, maybe Stephane knows. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-10 8:44 ` Peter Zijlstra @ 2014-07-10 8:52 ` Peter Zijlstra 2014-07-10 8:54 ` Peter Zijlstra 0 siblings, 1 reply; 17+ messages in thread From: Peter Zijlstra @ 2014-07-10 8:52 UTC (permalink / raw) To: Fabio Coatti Cc: Greg Kroah-Hartman, linux-kernel, eranian, mingo, acme, ak, zheng.z.yan On Thu, Jul 10, 2014 at 10:44:21AM +0200, Peter Zijlstra wrote: > On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: > > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha scritto: > > > > > Try cc:ing everyone on that patch, with the original information you > > > provided, and the linux-kernel mailing list. Those developers should be > > > able to help you out properly. > > > > Ok, here you can find the description of a problem that I'm experiencing on > > latest kernels, since 3.15.0. (this report comes from 3.15.4) > > > > lug 07 22:08:00 calvin kernel: resource map sanity check conflict: 0xfed10000 > > 0xfed15fff 0xfed10000 0xfed13fff reserved > > lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ > > I think this is a 'known' issue on Thinkpad (iirc). For some obscure > reason its BIOS has funny ideas about resources etc. > > I couldn't quickly find the prvious thread, maybe Stephane knows. Found it: lkml.kernel.org/r/20140224162400.GE16457@pd.tnic ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-10 8:52 ` Peter Zijlstra @ 2014-07-10 8:54 ` Peter Zijlstra 2014-07-10 12:13 ` Fabio Coatti 0 siblings, 1 reply; 17+ messages in thread From: Peter Zijlstra @ 2014-07-10 8:54 UTC (permalink / raw) To: Fabio Coatti Cc: Greg Kroah-Hartman, linux-kernel, eranian, mingo, acme, ak, zheng.z.yan On Thu, Jul 10, 2014 at 10:52:08AM +0200, Peter Zijlstra wrote: > On Thu, Jul 10, 2014 at 10:44:21AM +0200, Peter Zijlstra wrote: > > On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: > > > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha scritto: > > > > > > > Try cc:ing everyone on that patch, with the original information you > > > > provided, and the linux-kernel mailing list. Those developers should be > > > > able to help you out properly. > > > > > > Ok, here you can find the description of a problem that I'm experiencing on > > > latest kernels, since 3.15.0. (this report comes from 3.15.4) > > > > > > lug 07 22:08:00 calvin kernel: resource map sanity check conflict: 0xfed10000 > > > 0xfed15fff 0xfed10000 0xfed13fff reserved > > > lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ > > > > I think this is a 'known' issue on Thinkpad (iirc). For some obscure > > reason its BIOS has funny ideas about resources etc. > > > > I couldn't quickly find the prvious thread, maybe Stephane knows. > > Found it: > > lkml.kernel.org/r/20140224162400.GE16457@pd.tnic Ok, reread that thread and no definite conclusion was found I think. Just Thinkpad firmware having overlapping resources. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-10 8:54 ` Peter Zijlstra @ 2014-07-10 12:13 ` Fabio Coatti 2014-07-10 19:12 ` Stephane Eranian 0 siblings, 1 reply; 17+ messages in thread From: Fabio Coatti @ 2014-07-10 12:13 UTC (permalink / raw) To: Peter Zijlstra Cc: Greg Kroah-Hartman, linux-kernel, eranian, mingo, acme, ak, zheng.z.yan In data giovedì 10 luglio 2014 10:54:48, Peter Zijlstra ha scritto: > On Thu, Jul 10, 2014 at 10:52:08AM +0200, Peter Zijlstra wrote: > > On Thu, Jul 10, 2014 at 10:44:21AM +0200, Peter Zijlstra wrote: > > > On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: > > > > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha scritto: > > > > > Try cc:ing everyone on that patch, with the original information you > > > > > provided, and the linux-kernel mailing list. Those developers > > > > > should be > > > > > able to help you out properly. > > > > > > > > Ok, here you can find the description of a problem that I'm > > > > experiencing on > > > > latest kernels, since 3.15.0. (this report comes from 3.15.4) > > > > > > > > lug 07 22:08:00 calvin kernel: resource map sanity check conflict: > > > > 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff reserved > > > > lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ > > > > > > I think this is a 'known' issue on Thinkpad (iirc). For some obscure > > > reason its BIOS has funny ideas about resources etc. > > > > > > I couldn't quickly find the prvious thread, maybe Stephane knows. > > > > Found it: > > lkml.kernel.org/r/20140224162400.GE16457@pd.tnic > > Ok, reread that thread and no definite conclusion was found I think. > Just Thinkpad firmware having overlapping resources. So I guess that this happens also for HP Folio 9470m, not only in thinkpads. I wonder how many machines shares this behaviour... -- Fabio ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-10 12:13 ` Fabio Coatti @ 2014-07-10 19:12 ` Stephane Eranian 2014-07-10 20:05 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Stephane Eranian @ 2014-07-10 19:12 UTC (permalink / raw) To: Fabio Coatti Cc: Peter Zijlstra, Greg Kroah-Hartman, LKML, mingo, Arnaldo Carvalho de Melo, ak, Yan, Zheng, Bjorn Helgaas On Thu, Jul 10, 2014 at 2:13 PM, Fabio Coatti <fabio.coatti@gmail.com> wrote: > In data giovedì 10 luglio 2014 10:54:48, Peter Zijlstra ha scritto: >> On Thu, Jul 10, 2014 at 10:52:08AM +0200, Peter Zijlstra wrote: >> > On Thu, Jul 10, 2014 at 10:44:21AM +0200, Peter Zijlstra wrote: >> > > On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: >> > > > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha > scritto: >> > > > > Try cc:ing everyone on that patch, with the original information you >> > > > > provided, and the linux-kernel mailing list. Those developers >> > > > > should be >> > > > > able to help you out properly. >> > > > >> > > > Ok, here you can find the description of a problem that I'm >> > > > experiencing on >> > > > latest kernels, since 3.15.0. (this report comes from 3.15.4) >> > > > >> > > > lug 07 22:08:00 calvin kernel: resource map sanity check conflict: >> > > > 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff reserved >> > > > lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ >> > > >> > > I think this is a 'known' issue on Thinkpad (iirc). For some obscure >> > > reason its BIOS has funny ideas about resources etc. >> > > >> > > I couldn't quickly find the prvious thread, maybe Stephane knows. >> > >> > Found it: >> > lkml.kernel.org/r/20140224162400.GE16457@pd.tnic >> >> Ok, reread that thread and no definite conclusion was found I think. >> Just Thinkpad firmware having overlapping resources. > > > So I guess that this happens also for HP Folio 9470m, not only in thinkpads. I > wonder how many machines shares this behaviour... > Somehow, I thought that Bjorn had proposed a fix for this. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-10 19:12 ` Stephane Eranian @ 2014-07-10 20:05 ` Bjorn Helgaas 2014-07-11 7:38 ` Fabio Coatti 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2014-07-10 20:05 UTC (permalink / raw) To: Stephane Eranian Cc: Fabio Coatti, Peter Zijlstra, Greg Kroah-Hartman, LKML, mingo, Arnaldo Carvalho de Melo, ak, Yan, Zheng On Thu, Jul 10, 2014 at 09:12:44PM +0200, Stephane Eranian wrote: > On Thu, Jul 10, 2014 at 2:13 PM, Fabio Coatti <fabio.coatti@gmail.com> wrote: > > In data giovedì 10 luglio 2014 10:54:48, Peter Zijlstra ha scritto: > >> On Thu, Jul 10, 2014 at 10:52:08AM +0200, Peter Zijlstra wrote: > >> > On Thu, Jul 10, 2014 at 10:44:21AM +0200, Peter Zijlstra wrote: > >> > > On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: > >> > > > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha > > scritto: > >> > > > > Try cc:ing everyone on that patch, with the original information you > >> > > > > provided, and the linux-kernel mailing list. Those developers > >> > > > > should be > >> > > > > able to help you out properly. > >> > > > > >> > > > Ok, here you can find the description of a problem that I'm > >> > > > experiencing on > >> > > > latest kernels, since 3.15.0. (this report comes from 3.15.4) > >> > > > > >> > > > lug 07 22:08:00 calvin kernel: resource map sanity check conflict: > >> > > > 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff reserved > >> > > > lug 07 22:08:00 calvin kernel: ------------[ cut here ]------------ > >> > > > >> > > I think this is a 'known' issue on Thinkpad (iirc). For some obscure > >> > > reason its BIOS has funny ideas about resources etc. > >> > > > >> > > I couldn't quickly find the prvious thread, maybe Stephane knows. > >> > > >> > Found it: > >> > lkml.kernel.org/r/20140224162400.GE16457@pd.tnic > >> > >> Ok, reread that thread and no definite conclusion was found I think. > >> Just Thinkpad firmware having overlapping resources. > > > > > > So I guess that this happens also for HP Folio 9470m, not only in thinkpads. I > > wonder how many machines shares this behaviour... > > > Somehow, I thought that Bjorn had proposed a fix for this. Yep, this [1]: cb171f7abb9a PNP: Work around BIOS defects in Intel MCH area reporting which appeared in v3.15, so it should be in your kernel. But apparently it didn't work. Fabio, can you pastebin your complete dmesg log? [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb171f7abb9a ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-10 20:05 ` Bjorn Helgaas @ 2014-07-11 7:38 ` Fabio Coatti 2014-07-11 18:11 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Fabio Coatti @ 2014-07-11 7:38 UTC (permalink / raw) To: Bjorn Helgaas Cc: Stephane Eranian, Peter Zijlstra, Greg Kroah-Hartman, LKML, mingo, Arnaldo Carvalho de Melo, ak, Yan, Zheng In data giovedì 10 luglio 2014 14:05:27, Bjorn Helgaas ha scritto: > On Thu, Jul 10, 2014 at 09:12:44PM +0200, Stephane Eranian wrote: > > On Thu, Jul 10, 2014 at 2:13 PM, Fabio Coatti <fabio.coatti@gmail.com> wrote: > > > In data giovedì 10 luglio 2014 10:54:48, Peter Zijlstra ha scritto: > > >> On Thu, Jul 10, 2014 at 10:52:08AM +0200, Peter Zijlstra wrote: > > >> > On Thu, Jul 10, 2014 at 10:44:21AM +0200, Peter Zijlstra wrote: > > >> > > On Wed, Jul 09, 2014 at 12:48:05PM -0700, Fabio Coatti wrote: > > >> > > > In data mercoledì 9 luglio 2014 11:54:21, Greg Kroah-Hartman ha > > > > > > scritto: > > >> > > > > Try cc:ing everyone on that patch, with the original > > >> > > > > information you > > >> > > > > provided, and the linux-kernel mailing list. Those developers > > >> > > > > should be > > >> > > > > able to help you out properly. > > >> > > > > > >> > > > Ok, here you can find the description of a problem that I'm > > >> > > > experiencing on > > >> > > > latest kernels, since 3.15.0. (this report comes from 3.15.4) > > >> > > > > > >> > > > lug 07 22:08:00 calvin kernel: resource map sanity check > > >> > > > conflict: > > >> > > > 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff reserved > > >> > > > lug 07 22:08:00 calvin kernel: ------------[ cut here > > >> > > > ]------------ > > >> > > > > >> > > I think this is a 'known' issue on Thinkpad (iirc). For some > > >> > > obscure > > >> > > reason its BIOS has funny ideas about resources etc. > > >> > > > > >> > > I couldn't quickly find the prvious thread, maybe Stephane knows. > > >> > > > >> > Found it: > > >> > lkml.kernel.org/r/20140224162400.GE16457@pd.tnic > > >> > > >> Ok, reread that thread and no definite conclusion was found I think. > > >> Just Thinkpad firmware having overlapping resources. > > > > > > So I guess that this happens also for HP Folio 9470m, not only in > > > thinkpads. I wonder how many machines shares this behaviour... > > > > Somehow, I thought that Bjorn had proposed a fix for this. > > Yep, this [1]: > > cb171f7abb9a PNP: Work around BIOS defects in Intel MCH area reporting > > which appeared in v3.15, so it should be in your kernel. But apparently > it didn't work. Fabio, can you pastebin your complete dmesg log? > > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c > b171f7abb9a Sure, here you go: http://pastebin.com/FiL7N64b -- Fabio ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-11 7:38 ` Fabio Coatti @ 2014-07-11 18:11 ` Bjorn Helgaas 2014-07-15 20:33 ` Bjorn Helgaas 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2014-07-11 18:11 UTC (permalink / raw) To: Fabio Coatti Cc: Stephane Eranian, Peter Zijlstra, Greg Kroah-Hartman, LKML, mingo, Arnaldo Carvalho de Melo, ak, Yan, Zheng On Fri, Jul 11, 2014 at 1:38 AM, Fabio Coatti <fabio.coatti@gmail.com> wrote: > In data giovedì 10 luglio 2014 14:05:27, Bjorn Helgaas ha scritto: >> ... >> Fabio, can you pastebin your complete dmesg log? > > Sure, here you go: > > http://pastebin.com/FiL7N64b I opened this bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80041 and attached your dmesg to it. I see what the problem is, but I don't have a good idea yet for how to fix it. The problem is that we don't handle e820 and PNP device resource information correctly. From the attached dmesg, we have this: BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved system 00:00: [mem 0xfed10000-0xfed17fff] could not be reserved The 00:00 PNP device describes the correct 32K range for the Intel MCH (see [1] for details). But the [mem 0xfed10000-0xfed13fff] entry from e820 was added to the resource map first, and it covers only the first 16K of the MCH range. This caused the subsequent PNP reservation to fail. Then the snb_uncore_imc_init_box() reservation caused the warning, because it would be a child of the e820 entry but it covers more space. [1] fixed a similar issue where the PNP device described only the first 16K of the MCH range. This case is slightly different because here it's the e820 entry that is incorrect. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb171f7abb9a ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-11 18:11 ` Bjorn Helgaas @ 2014-07-15 20:33 ` Bjorn Helgaas 2014-07-15 23:40 ` Yinghai Lu 0 siblings, 1 reply; 17+ messages in thread From: Bjorn Helgaas @ 2014-07-15 20:33 UTC (permalink / raw) To: Fabio Coatti Cc: Stephane Eranian, Peter Zijlstra, Greg Kroah-Hartman, LKML, mingo, Arnaldo Carvalho de Melo, ak, Yan, Zheng, Yinghai Lu, Rafael J. Wysocki [+cc Yinghai, Rafael] On Fri, Jul 11, 2014 at 12:11 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Fri, Jul 11, 2014 at 1:38 AM, Fabio Coatti <fabio.coatti@gmail.com> wrote: >> In data giovedì 10 luglio 2014 14:05:27, Bjorn Helgaas ha scritto: >>> ... >>> Fabio, can you pastebin your complete dmesg log? >> >> Sure, here you go: >> >> http://pastebin.com/FiL7N64b > > I opened this bugzilla: > https://bugzilla.kernel.org/show_bug.cgi?id=80041 and attached your > dmesg to it. I see what the problem is, but I don't have a good idea > yet for how to fix it. > > The problem is that we don't handle e820 and PNP device resource > information correctly. From the attached dmesg, we have this: > > BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved > system 00:00: [mem 0xfed10000-0xfed17fff] could not be reserved > > The 00:00 PNP device describes the correct 32K range for the Intel MCH > (see [1] for details). But the [mem 0xfed10000-0xfed13fff] entry from > e820 was added to the resource map first, and it covers only the first > 16K of the MCH range. This caused the subsequent PNP reservation to > fail. Then the snb_uncore_imc_init_box() reservation caused the > warning, because it would be a child of the e820 entry but it covers > more space. > > [1] fixed a similar issue where the PNP device described only the > first 16K of the MCH range. This case is slightly different because > here it's the e820 entry that is incorrect. > > [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb171f7abb9a One of the reasons for iomem_resource is so we don't hand out the same address space to two different devices. We *could* do that by keeping track of the union of all devices and reserved areas that we know about. But the current resource code is more strict: it enforces a hierarchy. For example, in this case, it rejects the 00:00 PNP resource because it is larger than the e820 entry. The problem with rejecting it is that we might hand out [mem 0xfed14000-0xfed17fff] to another device even though PNP told us that it's in use. I'm about to head out for a few weeks of vacation, so I won't be able to do anything with this. Bjorn ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-15 20:33 ` Bjorn Helgaas @ 2014-07-15 23:40 ` Yinghai Lu 2014-07-15 23:54 ` H. Peter Anvin 0 siblings, 1 reply; 17+ messages in thread From: Yinghai Lu @ 2014-07-15 23:40 UTC (permalink / raw) To: Bjorn Helgaas, H. Peter Anvin Cc: Fabio Coatti, Stephane Eranian, Peter Zijlstra, Greg Kroah-Hartman, LKML, mingo, Arnaldo Carvalho de Melo, ak, Yan, Zheng, Rafael J. Wysocki On Tue, Jul 15, 2014 at 1:33 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > [+cc Yinghai, Rafael] > >>> http://pastebin.com/FiL7N64b >> >> I opened this bugzilla: >> https://bugzilla.kernel.org/show_bug.cgi?id=80041 and attached your >> dmesg to it. I see what the problem is, but I don't have a good idea >> yet for how to fix it. >> >> The problem is that we don't handle e820 and PNP device resource >> information correctly. From the attached dmesg, we have this: >> >> BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved >> system 00:00: [mem 0xfed10000-0xfed17fff] could not be reserved >> >> The 00:00 PNP device describes the correct 32K range for the Intel MCH >> (see [1] for details). But the [mem 0xfed10000-0xfed13fff] entry from >> e820 was added to the resource map first, and it covers only the first >> 16K of the MCH range. This caused the subsequent PNP reservation to >> fail. Then the snb_uncore_imc_init_box() reservation caused the >> warning, because it would be a child of the e820 entry but it covers >> more space. >> >> [1] fixed a similar issue where the PNP device described only the >> first 16K of the MCH range. This case is slightly different because >> here it's the e820 entry that is incorrect. >> >> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb171f7abb9a > > One of the reasons for iomem_resource is so we don't hand out the same > address space to two different devices. We *could* do that by keeping > track of the union of all devices and reserved areas that we know > about. > > But the current resource code is more strict: it enforces a hierarchy. > For example, in this case, it rejects the 00:00 PNP resource because > it is larger than the e820 entry. The problem with rejecting it is > that we might hand out [mem 0xfed14000-0xfed17fff] to another device > even though PNP told us that it's in use. > > I'm about to head out for a few weeks of vacation, so I won't be able > to do anything with this. In that case, we could reserve the whole MCH range in e820 from trim_snb_memory() instead. HPA, what is your idea about it? Yinghai ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-15 23:40 ` Yinghai Lu @ 2014-07-15 23:54 ` H. Peter Anvin 2014-07-16 0:56 ` Yinghai Lu 0 siblings, 1 reply; 17+ messages in thread From: H. Peter Anvin @ 2014-07-15 23:54 UTC (permalink / raw) To: Yinghai Lu, Bjorn Helgaas Cc: Fabio Coatti, Stephane Eranian, Peter Zijlstra, Greg Kroah-Hartman, LKML, Ingo Molnar, Arnaldo Carvalho de Melo, ak, Yan, Zheng, Rafael J. Wysocki On 07/15/2014 04:40 PM, Yinghai Lu wrote: >> >> One of the reasons for iomem_resource is so we don't hand out the same >> address space to two different devices. We *could* do that by keeping >> track of the union of all devices and reserved areas that we know >> about. >> >> But the current resource code is more strict: it enforces a hierarchy. >> For example, in this case, it rejects the 00:00 PNP resource because >> it is larger than the e820 entry. The problem with rejecting it is >> that we might hand out [mem 0xfed14000-0xfed17fff] to another device >> even though PNP told us that it's in use. >> >> I'm about to head out for a few weeks of vacation, so I won't be able >> to do anything with this. > > In that case, we could reserve the whole MCH range in e820 from > trim_snb_memory() instead. > > HPA, what is your idea about it? > > Yinghai > We could quirk it, but we would have to make bloody darn sure that we don't break any systems because of unusual configuration and so on. I agree that we need to treat fixed resources as equivalent to reserved. This is also a BIOS bug (it should reserve the whole region), but that happens far too frequently. I don't know if we have any way to do that without massive surgery to the current code, though. -hpa ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() 2014-07-15 23:54 ` H. Peter Anvin @ 2014-07-16 0:56 ` Yinghai Lu 0 siblings, 0 replies; 17+ messages in thread From: Yinghai Lu @ 2014-07-16 0:56 UTC (permalink / raw) To: H. Peter Anvin Cc: Bjorn Helgaas, Fabio Coatti, Stephane Eranian, Peter Zijlstra, Greg Kroah-Hartman, LKML, Ingo Molnar, Arnaldo Carvalho de Melo, ak, Yan, Zheng, Rafael J. Wysocki On Tue, Jul 15, 2014 at 4:54 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 07/15/2014 04:40 PM, Yinghai Lu wrote: > We could quirk it, but we would have to make bloody darn sure that we > don't break any systems because of unusual configuration and so on. > > I agree that we need to treat fixed resources as equivalent to reserved. > This is also a BIOS bug (it should reserve the whole region), but that > happens far too frequently. I don't know if we have any way to do that > without massive surgery to the current code, though. Should be similar to early_gart_iommu_check(), even less code. Yinghai ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-07-16 0:56 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CADpTngUm7d88RJS9OV=64t6QrJU4r3M_Z8eV1QYWPeeB5SX5-w@mail.gmail.com> 2014-07-07 20:47 ` WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x290/0x2fa() Greg Kroah-Hartman 2014-07-07 20:51 ` Fabio Coatti 2014-07-09 18:41 ` Fabio Coatti 2014-07-09 18:54 ` Greg Kroah-Hartman 2014-07-09 19:48 ` Fabio Coatti 2014-07-10 8:44 ` Peter Zijlstra 2014-07-10 8:52 ` Peter Zijlstra 2014-07-10 8:54 ` Peter Zijlstra 2014-07-10 12:13 ` Fabio Coatti 2014-07-10 19:12 ` Stephane Eranian 2014-07-10 20:05 ` Bjorn Helgaas 2014-07-11 7:38 ` Fabio Coatti 2014-07-11 18:11 ` Bjorn Helgaas 2014-07-15 20:33 ` Bjorn Helgaas 2014-07-15 23:40 ` Yinghai Lu 2014-07-15 23:54 ` H. Peter Anvin 2014-07-16 0:56 ` Yinghai Lu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.