On 2016-06-08 23:43, Xinxing Hu wrote:
Hi Yousong,
Thanks a lot for you patch. I tried it a little bit, and till now
everything looks OK. It seems this issue is solved by your patch.
Not sure whether Mats (the original reporter of this issue) still see
the issue or not.
Unfortunately I hav
Hi Yousong,
Thanks a lot for you patch. I tried it a little bit, and till now
everything looks OK. It seems this issue is solved by your patch.
Not sure whether Mats (the original reporter of this issue) still see
the issue or not.
Best Regards,
Xinxing
On 2016/6/7 20:49, Yousong Zhou wrot
On 7 June 2016 at 06:11, Xinxing Hu wrote:
> Hi Guys,
>
> I have another idea about this issue. Maybe it is not kernel, but uloop
> related. I read procd and libubox code a little bit, and it seems there is a
> potential issue existing in uloop_run().
>
> In general, uloop_run() is running in a wh
Hi Guys,
I have another idea about this issue. Maybe it is not kernel, but uloop
related. I read procd and libubox code a little bit, and it seems there
is a potential issue existing in uloop_run().
In general, uloop_run() is running in a while loop:
while()
1, Process timeouts list
On 2016-05-18 15:09, Mats Karrman wrote:
On 2016-05-18 14:03, Felix Fietkau wrote:
On 2016-05-18 14:00, Mats Karrman wrote:
On 2016-05-18 13:01, Felix Fietkau wrote:
On 2016-05-18 11:38, Mats Karrman wrote:
On 2016-05-17 17:31, Mats Karrman wrote:
On 2016-05-17 13:29, Felix Fietkau wrot
On 2016-05-18 14:00, Mats Karrman wrote:
>
>
> On 2016-05-18 13:01, Felix Fietkau wrote:
>> On 2016-05-18 11:38, Mats Karrman wrote:
>>>
>>> On 2016-05-17 17:31, Mats Karrman wrote:
On 2016-05-17 13:29, Felix Fietkau wrote:
> I just took a look at the code and uloop's processing of signa
On 2016-05-18 13:01, Felix Fietkau wrote:
On 2016-05-18 11:38, Mats Karrman wrote:
On 2016-05-17 17:31, Mats Karrman wrote:
On 2016-05-17 13:29, Felix Fietkau wrote:
I just took a look at the code and uloop's processing of signals looked
a bit racy to me. I've pushed a commit that makes it
On 2016-05-18 11:38, Mats Karrman wrote:
>
>
> On 2016-05-17 17:31, Mats Karrman wrote:
>>
>> On 2016-05-17 13:29, Felix Fietkau wrote:
>>> I just took a look at the code and uloop's processing of signals looked
>>> a bit racy to me. I've pushed a commit that makes it use signalfd if
>>> availabl
On 2016-05-17 17:31, Mats Karrman wrote:
On 2016-05-17 13:29, Felix Fietkau wrote:
I just took a look at the code and uloop's processing of signals looked
a bit racy to me. I've pushed a commit that makes it use signalfd if
available. I also found that waitpid wasn't being retried on signal
i
On 2016-05-17 13:29, Felix Fietkau wrote:
I just took a look at the code and uloop's processing of signals looked
a bit racy to me. I've pushed a commit that makes it use signalfd if
available. I also found that waitpid wasn't being retried on signal
interrupt, so I added an extra check there. T
Hi Mats,
On 2016-05-17 12:03, Mats Karrman wrote:
> Hi Felix, others,
>
> I have been experiencing problems with the init scripts dispatch
> suddenly stopping (indefinitely).
> This happens maybe once in 100 reboots.
> After inserting a new start script that launches another daemon
> (cgrulesen
Hi Felix, others,
I have been experiencing problems with the init scripts dispatch
suddenly stopping (indefinitely).
This happens maybe once in 100 reboots.
After inserting a new start script that launches another daemon
(cgrulesengd) very early in the boot process, the failures started to
co
12 matches
Mail list logo
