On 6 January 2014 16:47, Bjørn Mork wrote:
> Viresh Kumar writes:
>
>> On 6 January 2014 16:19, Bjørn Mork wrote:
>>> I cancelled by pressing backspace while the image was being written.
>>
>> I will answer other queries on next mail, but a quick question:
>> Do you get these warnings even if yo
On Monday, January 06, 2014 04:24:09 PM Viresh Kumar wrote:
> On 6 January 2014 16:19, Bjørn Mork wrote:
> > I cancelled by pressing backspace while the image was being written.
Basically, stuff is still frozen at this point, but devices are fully
functional. It's kind of like returning an error
On Monday, January 06, 2014 11:49:00 AM Bjørn Mork wrote:
> Viresh Kumar writes:
>
> > On 6 January 2014 14:31, Bjørn Mork wrote:
> >> That's correct. I have not observed this on suspend to RAM. But then
> >> again I haven't rigged any way to log that, so I don't think it's
> >> conclusive..
>
On 6 January 2014 16:19, Bjørn Mork wrote:
> I cancelled by pressing backspace while the image was being written.
I will answer other queries on next mail, but a quick question:
Do you get these warnings even if you don't cancel hibernation?
--
To unsubscribe from this list: send the line "unsubs
Viresh Kumar writes:
> On 6 January 2014 14:31, Bjørn Mork wrote:
>> That's correct. I have not observed this on suspend to RAM. But then
>> again I haven't rigged any way to log that, so I don't think it's
>> conclusive..
>>
>> The point I tried to make is that it isn't related to any hiberna
On 6 January 2014 14:31, Bjørn Mork wrote:
> That's correct. I have not observed this on suspend to RAM. But then
> again I haven't rigged any way to log that, so I don't think it's
> conclusive..
>
> The point I tried to make is that it isn't related to any hibernation
> *failures*. The warnin
Viresh Kumar writes:
> On 3 January 2014 17:25, Bjørn Mork wrote:
>> Correct. And users not running a lock debugging kernel will of course
>> not even see the warning.
>
> Okay..
>
>>> - It only happens when cpufreq_add_dev() fails during hibernation while
>>> we enable non-boot CPUs again to sav
On 3 January 2014 17:25, Bjørn Mork wrote:
> Correct. And users not running a lock debugging kernel will of course
> not even see the warning.
Okay..
>> - It only happens when cpufreq_add_dev() fails during hibernation while
>> we enable non-boot CPUs again to save image to disk. So, isn't a pro
Viresh Kumar writes:
> On 3 January 2014 15:23, Bjørn Mork wrote:
>> Note that "ondemand" and "1401000" are the default vaules, so I don't
>> actually change anything here. The write is causing the problem, not
>> the value. As expected, I guess.
>>
>> Also note that boot vs non-boot cpu doesn
On 3 January 2014 15:23, Bjørn Mork wrote:
> Note that "ondemand" and "1401000" are the default vaules, so I don't
> actually change anything here. The write is causing the problem, not
> the value. As expected, I guess.
>
> Also note that boot vs non-boot cpu doesn't seem to matter. Nor does
>
Bjørn Mork writes:
> "Rafael J. Wysocki" writes:
>
>> OK, thanks! Well, this is somewhat worrisome.
>>
>> Could you also check the linux-pm.git/fixes branch that contains all patches
>> I'm planning to push for 3.13-rc7 shortly?
>
> It's definitely still there. But I'm less sure about the exact
"Rafael J. Wysocki" writes:
> OK, thanks! Well, this is somewhat worrisome.
>
> Could you also check the linux-pm.git/fixes branch that contains all patches
> I'm planning to push for 3.13-rc7 shortly?
It's definitely still there. But I'm less sure about the exact trigger.
I have now booted a
On Thursday, January 02, 2014 01:15:10 PM Bjørn Mork wrote:
> "Rafael J. Wysocki" writes:
>
> > On Tuesday, December 24, 2013 07:11:00 AM Viresh Kumar wrote:
> >> __cpufreq_add_dev() can fail sometimes while we are resuming our system.
> >> Currently we are clearing all sysfs nodes for cpufreq's
"Rafael J. Wysocki" writes:
> On Tuesday, December 24, 2013 07:11:00 AM Viresh Kumar wrote:
>> __cpufreq_add_dev() can fail sometimes while we are resuming our system.
>> Currently we are clearing all sysfs nodes for cpufreq's failed policy as that
>> could make userspace unstable. But if we susp
Yes, that's good. As you might have guessed by the lack of any response, I
won't be able to test this in 2013.
Thanks for all the good work!
Bjørn
Viresh Kumar wrote:
>On 27 December 2013 15:27, Viresh Kumar
>wrote:
>> I think there is nothing much different in this patch compared to
>what
On 27 December 2013 15:27, Viresh Kumar wrote:
> I think there is nothing much different in this patch compared to what Bjorn
> tested. So you can probably push that now and let him test linux-next later
> once he is back?
Just saw that you already pushed it. :)
--
To unsubscribe from this list:
On 26 December 2013 08:17, Viresh Kumar wrote:
> On 26 December 2013 06:35, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>> Subject: cpufreq: Clean up after a failing light-weight initialization
>>
>> If cpufreq_policy_restore() returns NULL during system resume,
>> __cpufreq_add_dev() sh
On 26 December 2013 06:35, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: cpufreq: Clean up after a failing light-weight initialization
>
> If cpufreq_policy_restore() returns NULL during system resume,
> __cpufreq_add_dev() should just fall back to the full initialization
> instea
On Tuesday, December 24, 2013 07:11:00 AM Viresh Kumar wrote:
> __cpufreq_add_dev() can fail sometimes while we are resuming our system.
> Currently we are clearing all sysfs nodes for cpufreq's failed policy as that
> could make userspace unstable. But if we suspend/resume again, we should
> atle
__cpufreq_add_dev() can fail sometimes while we are resuming our system.
Currently we are clearing all sysfs nodes for cpufreq's failed policy as that
could make userspace unstable. But if we suspend/resume again, we should atleast
try to bring back those policies.
This patch fixes this issue by c
20 matches
Mail list logo
