> Am 27.04.2015 um 09:23 schrieb Richard Weinberger
> :
>
Hi Richard,
> mea culpa!
> If I forget a patch, just shout at me.
I crawled through the mailing list, you may want to also check these:
http://sourceforge.net/p/user-mode-linux/mailman/message/32922307/
http://sourceforge.net/p/user-m
On 27/04/15 08:23, Richard Weinberger wrote:
> On Mon, Apr 27, 2015 at 7:47 AM, Anton Ivanov
> wrote:
>> On 26/04/15 22:00, Richard Weinberger wrote:
> Can you give the attached patch a try?
> Let's see if it proves my theory.
> Looks like UML's clocksource needs fixing.
Hi Richar
On Mon, Apr 27, 2015 at 7:47 AM, Anton Ivanov
wrote:
> On 26/04/15 22:00, Richard Weinberger wrote:
>>
Can you give the attached patch a try?
Let's see if it proves my theory.
Looks like UML's clocksource needs fixing.
>>> Hi Richard,
>>>
>>> I did run this for an hour and did 4 sus
On 26/04/15 22:00, Richard Weinberger wrote:
>
>>> Can you give the attached patch a try?
>>> Let's see if it proves my theory.
>>> Looks like UML's clocksource needs fixing.
>> Hi Richard,
>>
>> I did run this for an hour and did 4 suspend/resume cycles and it seems
>> not to hang any more!
> Yay!
Hi!
Am 26.04.2015 um 22:57 schrieb Thomas Meyer:
> Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger:
>> On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote:
>>> Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
>
Am Sonntag, den 26.04.2015, 20:32 +0200 schrieb Richard Weinberger:
> On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote:
> > Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
> >> Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
> >> >> Hmm, does this always happen?
> >> >
> >> > Ye
Am 26.04.2015 um 20:32 schrieb Richard Weinberger:
> On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote:
>> Any ideas?
>
> Can you give the attached patch a try?
> Let's see if it proves my theory.
> Looks like UML's clocksource needs fixing.
Please give also this patch a try.
I should fix your
On Fri, Apr 24, 2015 at 9:58 PM, Thomas Meyer wrote:
> Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
>> Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
>> >> Hmm, does this always happen?
>> >
>> > Yes, my single core system seems to trigger this every time after resume
>> > fro
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
> Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
> >> Hmm, does this always happen?
> >
> > Yes, my single core system seems to trigger this every time after resume
> > from ram.
>
> What is your host kernel?
>
> >> At least on my
Am Montag, den 20.10.2014, 11:56 +0200 schrieb Richard Weinberger:
> Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
> >> Hmm, does this always happen?
> >
> > Yes, my single core system seems to trigger this every time after resume
> > from ram.
>
> What is your host kernel?
The standard Fedora k
Am 20.10.2014 um 11:51 schrieb Thomas Meyer:
>> Hmm, does this always happen?
>
> Yes, my single core system seems to trigger this every time after resume from
> ram.
What is your host kernel?
>> At least on my notebook it did not happen. I've started an UML yesterday
>> suspended it and after
Am 20.10.2014 10:27 schrieb Richard Weinberger :
>
> On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer wrote:
> > Hello,
> >
> > in UML kernel I get a long cpu using loop in __getnstimeofday()
> > (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(),
> > when I left the host kernel su
On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer wrote:
> Hello,
>
> in UML kernel I get a long cpu using loop in __getnstimeofday()
> (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(),
> when I left the host kernel suspended to ram for a few hours and resume
> again.
> this is because
13 matches
Mail list logo
