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
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
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
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
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
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
Hi,
On Tue, Feb 25, 2014 at 11:10 PM, Borislav Petkov wrote:
> On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
>
>> I am on tip.git at cfbf8d4 Linux 3.14-rc4.
>> and I don't see the problem (using Ubuntu Saucy).
>
> Also IVB, model 58?
>
Yes.
>> Given what you commented out,
On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
> I am on tip.git at cfbf8d4 Linux 3.14-rc4.
> and I don't see the problem (using Ubuntu Saucy).
Also IVB, model 58?
> Given what you commented out, it seems like you're saying
> something goes wrong with pci_get_device().
On Tue, Feb 25, 2014 at 6:39 PM, Borislav Petkov wrote:
> On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
>> No, it's a T430s. What happens if you boot vanilla tip.git?
>
> linus/master + tip/master -> fails
> tip/master-> fails
>
> All trees are from today, like
On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
> No, it's a T430s. What happens if you boot vanilla tip.git?
linus/master + tip/master -> fails
tip/master-> fails
All trees are from today, like an hour ago or so.
Doing what hpa suggested:
diff --git
On Tue, Feb 25, 2014 at 5:30 PM, Borislav Petkov wrote:
> On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
>> I am trying to understand your test case.
>> Were you actually measure uncore_imc events at the time you suspended?
>
> No test case, just the machine booting; look at
On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
> I am trying to understand your test case.
> Were you actually measure uncore_imc events at the time you suspended?
No test case, just the machine booting; look at the printk timestamps.
> I tried on my IvyBridge Lenovo and it
Hi,
I am trying to understand your test case.
Were you actually measure uncore_imc events at the time you suspended?
I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ (tip.git).
I used: echo -n disk >/sys/power/state
On Tue, Feb 25, 2014 at 4:48 PM, H. Peter Anvin wrote:
> On
On 02/24/2014 12:19 PM, Borislav Petkov wrote:
> Btw,
>
> I don't know whether the following observation is related or not, but it
> so happens that after resume from suspend-to-disk, I see the booting up
> of the resume kernel on the console but when it is time for the original
> kernel to take
ity 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 ke
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 )
11/13/2012
[0.490742] 00ab 880213d01ad8 816112e3
25 matches
Mail list logo