ler+0x233/0x380()
> Info: mapping multiple BARs. Your kernel is fine.
...
> [] __ioremap_caller+0x233/0x380
> [] ? snb_uncore_imc_init_box+0x6d/0xa0
> [] ioremap_nocache+0x26/0x40
> [] snb_uncore_imc_init_box+0x6d/0xa0
>
> Should I worry about that ?
I don't think so. I
ler+0x233/0x380()
> Info: mapping multiple BARs. Your kernel is fine.
...
> [] __ioremap_caller+0x233/0x380
> [] ? snb_uncore_imc_init_box+0x6d/0xa0
> [] ioremap_nocache+0x26/0x40
> [] snb_uncore_imc_init_box+0x6d/0xa0
>
> Should I worry about that ?
I don't think so. I
Starting with 4.1 and still in 4.3-rc7 I get this in dmesg during boot phase at
a 64 bit Gentoo Linux at a Lenovo T440s:
[ cut here ]
WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:191
__ioremap_caller+0x233/0x380()
Info: mapping multiple BARs. Your kernel is fine
Starting with 4.1 and still in 4.3-rc7 I get this in dmesg during boot phase at
a 64 bit Gentoo Linux at a Lenovo T440s:
[ cut here ]
WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:191
__ioremap_caller+0x233/0x380()
Info: mapping multiple BARs. Your kernel is fine
On Thu, Apr 17, 2014 at 05:30:27PM -0400, Dave Jones wrote:
> I think it's just implicated because that's the next thing that seems
> to init after the modeswitch. The config differences are small, just
> things like =m instead of =y or vice-versa.
>
> I'm about to head into a long weekend, so
On Thu, Apr 17, 2014 at 05:30:27PM -0400, Dave Jones wrote:
I think it's just implicated because that's the next thing that seems
to init after the modeswitch. The config differences are small, just
things like =m instead of =y or vice-versa.
I'm about to head into a long weekend, so I'll get
On Thu, Apr 17, 2014 at 04:53:55PM -0400, Dave Jones wrote:
> ok, with your config I get back to a console after the modesetting
> switch, but then it hangs in USB init.
Maybe because of our machines are not that similar there? Can you take
my config but paste the usb part of yours and see
On Thu, Apr 17, 2014 at 04:03:52PM -0400, Dave Jones wrote:
> On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
> > On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
> > > Just as X starts up, I see this in dmesg..
> > >
> > > [ 42.879049]
or (theoretically) a
>> device conflict if we assigned the unreported space to another device.
>>
>> The Intel perf event uncore driver tripped over this when it claimed the
>> MCH region:
>>
>> resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed100
On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
> On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
> > Just as X starts up, I see this in dmesg..
> >
> > [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
> > underrun
>
> FWIW, I have that
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
> Just as X starts up, I see this in dmesg..
>
> [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
> underrun
FWIW, I have that too. It should be something i915-related:
[0.617673] [drm] Memory usable by
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
> Thanks a lot for testing this out and debugging my issues.
>
> Here's a new version that looks for both device IDs I know about.
I can confirm this patch does fix the backtrace.
I disabled lockdep, and now I can get to X each
e
> MCH region:
>
> resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed10000
> 0xfed13fff pnp 00:01
> Info: mapping multiple BARs. Your kernel is fine.
>
> To prevent this, if we find a PNP0C02 resource that covers part of the MCH
> space, extend it
or (theoretically) a
device conflict if we assigned the unreported space to another device.
The Intel perf event uncore driver tripped over this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel
iver tripped over this when it claimed the
> MCH region:
>
> resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000
> 0xfed13fff pnp 00:01
> Info: mapping multiple BARs. Your kernel is fine.
>
> To prevent this, if we find a PNP0C02 resource that covers part of
region:
resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.
Link: http
BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.
Link: http://lkml.kernel.org/r/20140224162400.ge16...@pd.tnic
Reported-by: Borislav Petkov b...@alien8.de
Signed-off-by: Bjorn Helgaas bhelg
0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.
Link: http://lkml.kernel.org/r/20140224162400.ge16...@pd.tnic
Reported
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
Thanks a lot for testing this out and debugging my issues.
Here's a new version that looks for both device IDs I know about.
I can confirm this patch does fix the backtrace.
I disabled lockdep, and now I can get to X each boot,
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
Just as X starts up, I see this in dmesg..
[ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
underrun
FWIW, I have that too. It should be something i915-related:
[0.617673] [drm] Memory usable by graphics
On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
Just as X starts up, I see this in dmesg..
[ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
underrun
FWIW, I have that too. It
it claimed the
MCH region:
resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.
Link
On Thu, Apr 17, 2014 at 04:03:52PM -0400, Dave Jones wrote:
On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
Just as X starts up, I see this in dmesg..
[ 42.879049] [drm:cpt_serr_int_handler]
On Thu, Apr 17, 2014 at 04:53:55PM -0400, Dave Jones wrote:
ok, with your config I get back to a console after the modesetting
switch, but then it hangs in USB init.
Maybe because of our machines are not that similar there? Can you take
my config but paste the usb part of yours and see whether
0.420713] [ cut here ]
[0.420810] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x2dd/0x380()
[0.420962] Info: mapping multiple BARs. Your kernel is fine.
[0.421012] Modules linked in:
[0.421235] CPU: 0 PID: 1 Comm: swapper/0 Not
On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian wrote:
> On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas wrote:
>> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
>>> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
>>> > Right. Even if we had this long-term
anity check warnings or (theoretically) a
> device conflict if we assigned the unreported space to another device.
>
> The Intel perf event uncore driver tripped over this when it claimed the
> MCH region:
>
> resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
l BIOSes still report a PNP0C02 resource that is
only 16KB, which means the rest of the MCH space is consumed but
unreported.
This can cause resource map sanity check warnings or (theoretically) a
device conflict if we assigned the unreported space to another device.
The Intel perf event uncore
On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote:
> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
> > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> > > Right. Even if we had this long-term solution, we'd still have
> > > Stephane's current
ty check warnings or (theoretically) a
device conflict if we assigned the unreported space to another device.
The Intel perf event uncore driver tripped over this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000
0xfed13fff pnp 00:01
Info: m
; Stephane Eranian; Yan, Zheng Z
> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> Importance: High
>
> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> > Right. Even if we had this long-term solution, we'd still have
> > Stephane's current
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> Right. Even if we had this long-term solution, we'd still have
> Stephane's current problem, because the PNP0C02 _CRS is still wrong.
>
> We do have a drivers/pnp/quirks.c where we could conceivably adjust
> the PNP resource if we
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem, because the PNP0C02 _CRS is still wrong.
We do have a drivers/pnp/quirks.c where we could conceivably adjust
the PNP resource if we found
, Zheng Z
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem, because the PNP0C02 _CRS is still wrong.
We do
conflict if we assigned the unreported space to another device.
The Intel perf event uncore driver tripped over this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent
On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote:
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem,
the unreported space to another device.
The Intel perf event uncore driver tripped over this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02
this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed1 0xfed15fff 0xfed1
0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire
On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian eran...@google.com wrote:
On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if
+0x2dd/0x380()
[0.420962] Info: mapping multiple BARs. Your kernel is fine.
[0.421012] Modules linked in:
[0.421235] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.15.0-0.rc1.git0.1.fc21.x86_64 #1
[0.421377] Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 )
04/30/2013
On Thu, Mar 20, 2014 at 2:55 PM, Rafael J. Wysocki wrote:
> On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
>> The purpose of system.c is indeed to prevent resources from being
>> allocated to other devices. This is really a question for Rafael, but
>> in my opinion this function
On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
> On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui wrote:
>
> > I've talked with Yan Zheng, and I was told that this resource "0xfed1 -
> > 0xfed15fff"
> > is got from PCI device register directly, which is not in its BAR range.
> >
On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui wrote:
> I've talked with Yan Zheng, and I was told that this resource "0xfed1 -
> 0xfed15fff"
> is got from PCI device register directly, which is not in its BAR range.
> Thus IMO, it is impossible for PNP layer to be aware of this resource.
On Thu, Mar 20, 2014 at 9:16 AM, Yan, Zheng wrote:
> On 03/20/2014 03:53 PM, Zhang, Rui wrote:
>> The resource length is also hardcoded to 0x6000, right?
>> This is probably a problem, because
>> only if the resource length read from PCI config space is larger than 0x4000,
>> drivers/pnp/quirks.c
On Thu, 2014-03-20 at 16:16 +0800, Yan, Zheng wrote:
> On 03/20/2014 03:53 PM, Zhang, Rui wrote:
> > The resource length is also hardcoded to 0x6000, right?
> > This is probably a problem, because
> > only if the resource length read from PCI config space is larger than
> > 0x4000,
> >
lkml; x...@kernel.org;
> > Bjorn Helgaas; Linux PCI; ACPI Devel Maling List; Yinghai Lu; H. Peter
> > Anvin; Yan, Zheng Z
> > Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> > Importance: High
> >
> > On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui
Devel Maling
> > List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian
> > Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> > Importance: High
> >
> > On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
> > > [CC list rearranged]
&g
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
> The resource length is also hardcoded to 0x6000, right?
> This is probably a problem, because
> only if the resource length read from PCI config space is larger than 0x4000,
> drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02
>
nghai Lu; H. Peter
> Anvin; Yan, Zheng Z
> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> Importance: High
>
> On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui wrote:
> >
> >
> >> -Original Message-
> >> From: Lu, Aaron
> >> Sent
, Zheng Z
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui rui.zh...@intel.com wrote:
-Original Message-
From: Lu, Aaron
Sent: Thursday, March 20, 2014 10:24 AM
To: Rafael J. Wysocki; Borislav Petkov
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
The resource length is also hardcoded to 0x6000, right?
This is probably a problem, because
only if the resource length read from PCI config space is larger than 0x4000,
drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02
resource
. Peter Anvin; Stephane Eranian
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning
; ACPI Devel Maling List; Yinghai Lu; H. Peter
Anvin; Yan, Zheng Z
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui rui.zh...@intel.com wrote:
-Original Message-
From: Lu, Aaron
Sent
On Thu, 2014-03-20 at 16:16 +0800, Yan, Zheng wrote:
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
The resource length is also hardcoded to 0x6000, right?
This is probably a problem, because
only if the resource length read from PCI config space is larger than
0x4000,
drivers/pnp/quirks.c
On Thu, Mar 20, 2014 at 9:16 AM, Yan, Zheng zheng.z@intel.com wrote:
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
The resource length is also hardcoded to 0x6000, right?
This is probably a problem, because
only if the resource length read from PCI config space is larger than 0x4000,
On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui rui.zh...@intel.com wrote:
I've talked with Yan Zheng, and I was told that this resource 0xfed1 -
0xfed15fff
is got from PCI device register directly, which is not in its BAR range.
Thus IMO, it is impossible for PNP layer to be aware of this
On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui rui.zh...@intel.com wrote:
I've talked with Yan Zheng, and I was told that this resource 0xfed1 -
0xfed15fff
is got from PCI device register directly, which is not in its BAR
On Thu, Mar 20, 2014 at 2:55 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
The purpose of system.c is indeed to prevent resources from being
allocated to other devices. This is really a question for Rafael, but
in my opinion this
g
>> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian
>> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
>> Importance: High
>>
>> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
>> > [CC list rearranged]
>> >
>
invoke acpi_check_reserved_resource() when assigning
resources to PCI devices.
Thanks,
rui
> Thanks,
> Aaron
>
> >
> >> ...
> >> [0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB)
> mapped at [ffff8800cac3-ffff8800cec2ffff]
> >&
0xcec3] (64MB) mapped at
>>> [8800cac3-ffff8800cec2]
>>> [ 0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff
>>> 0xfed1 0xfed13fff pnp 00:01
>>> [0.490079] [ cut here ]
>>> [0.490204] WARNIN
0.488998] software IO TLB [mem 0xcac3-0xcec3] (64MB) mapped at
>> [8800cac3-8800cec2]
>> [0.489975] resource map sanity check conflict: 0xfed1 0xfed15fff
>> 0xfed1 0xfed13fff pnp 00:01
>> [ 0.490079] ----[ cut here ]
&g
[0.490079] [ cut here ]
[0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x372/0x380()
[0.490306] Info: mapping multiple BARs. Your kernel is fine.
[0.490371] Modules linked in:
[0.490558] CPU: 2 PID: 1 Comm: swapper/0
check conflict: 0xfed1 0xfed15fff
0xfed1 0xfed13fff pnp 00:01
[0.490079] [ cut here ]
[0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x372/0x380()
[0.490306] Info: mapping multiple BARs. Your kernel is fine
]
[0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x372/0x380()
[0.490306] Info: mapping multiple BARs. Your kernel is fine.
[0.490371] Modules linked in:
[0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+
#1
Lu; H. Peter Anvin; Stephane Eranian
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning
On Monday, March 17, 2014 01:09:39 AM Rafael J. Wysocki wrote:
> On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
> > Rafael,
> >
> > Thanks for the analysis.
> >
> > On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> > > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J.
On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
> Rafael,
>
> Thanks for the analysis.
>
> On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
> >> I've just gone throught this.
> >
> > Thanks.
> >
> >> So
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
>> I've just gone throught this.
>
> Thanks.
>
>> So the problem is that we have the PNP "system" driver whose only purpose
>> seems
>>
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
> I've just gone throught this.
Thanks.
> So the problem is that we have the PNP "system" driver whose only purpose
> seems
> to be to reserve system resources so that the PCI layer doesn't assign them to
> new devices on
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
I've just gone throught this.
Thanks.
So the problem is that we have the PNP system driver whose only purpose
seems
to be to reserve system resources so that the PCI layer doesn't assign them to
new devices on hotplug
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
I've just gone throught this.
Thanks.
So the problem is that we have the PNP system driver whose only purpose
seems
On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
I've just gone throught this.
Thanks.
So the
On Monday, March 17, 2014 01:09:39 AM Rafael J. Wysocki wrote:
On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J.
79] [ cut here ]
> [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171
> __ioremap_caller+0x372/0x380()
> [0.490306] Info: mapping multiple BARs. Your kernel is fine.
> [0.490371] Modules linked in:
> [0.490558] CPU: 2 PID: 1 Comm: swa
/ioremap.c:171
__ioremap_caller+0x372/0x380()
[0.490306] Info: mapping multiple BARs. Your kernel is fine.
[0.490371] Modules linked in:
[0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #1
[0.490642] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06
Hi,
Any update on this problem?
On Thu, Feb 27, 2014 at 11:21 PM, Borislav Petkov wrote:
> On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
>> I won't be able to look at that before Monday I'm afraid (personal
>> stuff).
>
> No worries, sir, whenever. It can wait.
>
> Thanks a
Hi,
Any update on this problem?
On Thu, Feb 27, 2014 at 11:21 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
I won't be able to look at that before Monday I'm afraid (personal
stuff).
No worries, sir, whenever. It can wait.
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
> I won't be able to look at that before Monday I'm afraid (personal
> stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> > there to BAR is at a completely different address. Same thing on my
> > Haswell
On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
>> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra
>> wrote:
>> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> >> As a asides, my SNB and HSW
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra wrote:
> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> >> They hang if I type
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
>> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
>> not so sure
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
> not so sure this is all related to the uncore IMC support, though.
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> there to BAR is at a completely different address. Same thing on my
> Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what
On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov wrote:
> Can you please, pretty please, not top-post...
>
> On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
>> Hi,
>>
>> Ok, so I am getting the same error message as you.
>> I checked my syslog now.
>>
>> I have my uncore_imc
On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov b...@alien8.de wrote:
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
Hi,
Ok, so I am getting the same error message as you.
I checked my syslog now.
I have my uncore_imc
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
there to BAR is at a completely different address. Same thing on my
Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what we're
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
not so sure this is all related to the uncore IMC support, though.
Unstable
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They
On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a
On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
there to BAR is at a completely different address. Same thing on my
Haswell desktop
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
I won't be able to look at that before Monday I'm afraid (personal
stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
I don't think so because
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
The driver causing this is new
0.490079] [ cut here ]
> [0.490204] WARNING: CPU: 2 PID: 1 at arch/x86/mm/ioremap.c:171
> __ioremap_caller+0x372/0x380()
> [ 0.490306] Info: mapping multiple BARs. Your kernel is fine.
> [0.490371] Modules linked in:
> [0.490558] CPU: 2 PID: 1 Comm: swapper/0 Not taint
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
> Hi,
>
> Ok, so I am getting the same error message as you.
> I checked my syslog now.
>
> I have my uncore_imc addr=0xfed1 (after masking)
>
> And I also have pnp 00:01
cac3-0xcec3] (64MB) mapped at
> [8800cac3-8800cec2]
> [0.484971] DBG: will get device: 0x8086:154
> [0.485054] DBG: Got device, bus: 0x0
> [0.485254] DBG: ioremapping addr: 0xfed1
> [0.485356] resource map sanity check conflict: 0xfed1 0xfed15
PID: 1 at arch/x86/mm/ioremap.c:171
__ioremap_caller+0x372/0x380()
[ 0.485643] Info: mapping multiple BARs. Your kernel is fine.
[0.485709] Modules linked in:
[0.485935] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #6
[0.486019] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2
1 - 100 of 126 matches
Mail list logo
