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 and
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
commit
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
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 over
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 h...@zytor.com
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 works
On Tue, Feb 25, 2014 at 5:30 PM, Borislav Petkov b...@alien8.de 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;
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 6:39 PM, Borislav Petkov b...@alien8.de 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,
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().
Probably.
Hi,
On Tue, Feb 25, 2014 at 11:10 PM, Borislav Petkov b...@alien8.de 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
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 over and switch to graphics, the screen remains black but
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 over and switch to graphics, the screen remains black but
101 - 120 of 120 matches
Mail list logo
