On 02/11/15 22:13, Anton Ivanov wrote:
> On 02/11/15 21:50, Richard Weinberger wrote:
>> Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
>>> -void idle_sleep(unsigned long long nsecs)
>>> +/**
>>> + * os_idle_sleep() - sleep for a given time of nsecs
>>> + * @nsecs: nanoseconds to sleep
>>> + */
>>> +
On 02/11/15 21:50, Richard Weinberger wrote:
> Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
>> -void idle_sleep(unsigned long long nsecs)
>> +/**
>> + * os_idle_sleep() - sleep for a given time of nsecs
>> + * @nsecs: nanoseconds to sleep
>> + */
>> +void os_idle_sleep(unsigned long long nsecs)
>>
Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
> -void idle_sleep(unsigned long long nsecs)
> +/**
> + * os_idle_sleep() - sleep for a given time of nsecs
> + * @nsecs: nanoseconds to sleep
> + */
> +void os_idle_sleep(unsigned long long nsecs)
> {
> struct timespec ts;
>
> - /*
> -
On 02/11/15 15:25, Richard Weinberger wrote:
> Am 02.11.2015 um 15:30 schrieb Anton Ivanov:
>> On 02/11/15 10:01, Richard Weinberger wrote:
>>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
[snip]
>>> I'm pretty sure that you don't see the issue as your Jessy userspace
>>> uses na
Background: UML is using an obsolete itimer call for
all timers and "polls" for kernel space timer firing
in its userspace portion resulting in a long list
of bugs and incorrect behaviour(s). It also uses
ITIMER_VIRTUAL for its timer which results in the
timer being dependent on it running and the
Am 02.11.2015 um 15:30 schrieb Anton Ivanov:
> On 02/11/15 10:01, Richard Weinberger wrote:
>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>>> [snip]
>>>
>> I'm pretty sure that you don't see the issue as your Jessy userspace
>> uses nanosleep periodically.
> There are quite a few thi
On 02/11/15 10:01, Richard Weinberger wrote:
> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>> [snip]
>>
> I'm pretty sure that you don't see the issue as your Jessy userspace uses
> nanosleep periodically.
There are quite a few things running so this may indeed be the case.
On 02/11/15 10:59, Anton Ivanov wrote:
> On 02/11/15 10:01, Richard Weinberger wrote:
>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>>> [snip]
>>>
>> I'm pretty sure that you don't see the issue as your Jessy
>> userspace uses nanosleep periodically.
> There are quite a few things ru
On 02/11/15 10:01, Richard Weinberger wrote:
> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>> [snip]
>>
> I'm pretty sure that you don't see the issue as your Jessy userspace uses
> nanosleep periodically.
There are quite a few things running so this may indeed be the case.
Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
> [snip]
>
I'm pretty sure that you don't see the issue as your Jessy userspace uses
nanosleep periodically.
>>> There are quite a few things running so this may indeed be the case.
>>>
>>> What do you use for userspace (so I can try to repro
[snip]
>>> I'm pretty sure that you don't see the issue as your Jessy userspace uses
>>> nanosleep periodically.
>> There are quite a few things running so this may indeed be the case.
>>
>> What do you use for userspace (so I can try to reproduce this and debug it)?
> Debian Squeeze amd64 with a
Am 02.11.2015 um 09:57 schrieb Anton Ivanov:
> On 02/11/15 08:52, Richard Weinberger wrote:
>> Am 02.11.2015 um 09:41 schrieb Anton Ivanov:
>>> On 02/11/15 08:37, Richard Weinberger wrote:
Hi!
Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
> I was testing under similar conditions (
On 02/11/15 08:52, Richard Weinberger wrote:
> Am 02.11.2015 um 09:41 schrieb Anton Ivanov:
>> On 02/11/15 08:37, Richard Weinberger wrote:
>>> Hi!
>>>
>>> Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
I was testing under similar conditions (CPU pinning using taskset -c 0 on
a multicore).
Am 02.11.2015 um 09:41 schrieb Anton Ivanov:
> On 02/11/15 08:37, Richard Weinberger wrote:
>> Hi!
>>
>> Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
>>> I was testing under similar conditions (CPU pinning using taskset -c 0 on a
>>> multicore).
>>>
>>> I have removed it and run some retests - I c
On 02/11/15 08:37, Richard Weinberger wrote:
> Hi!
>
> Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
>> I was testing under similar conditions (CPU pinning using taskset -c 0 on a
>> multicore).
>>
>> I have removed it and run some retests - I cannot reproduce the hang at this
>> point with my con
Hi!
Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
> I was testing under similar conditions (CPU pinning using taskset -c 0 on a
> multicore).
>
> I have removed it and run some retests - I cannot reproduce the hang at this
> point with my config
>
> I am going to run a defconfig and compare the
I was testing under similar conditions (CPU pinning using taskset -c 0
on a multicore).
I have removed it and run some retests - I cannot reproduce the hang at
this point with my config
I am going to run a defconfig and compare the results to see if this
will give me any insights on the root c
17 matches
Mail list logo
