On 02/19/2014 04:27 PM, Steven Rostedt wrote:
> Hmm, I wonder if this is because msleep() sets the tasks state to
> TASK_UNINTERRUPTIBLE, and hrtimer_nanosleep sets it to
> TASK_INTERRUPTIBLE.
No, it is because freezable_schedule() is called via do_nanosleep() in
hrtimer call path and msleep()
On Wed, 19 Feb 2014 12:53:53 +0100
Sebastian Andrzej Siewior wrote:
> Since we replaced msleep() by hrtimer I see now and then (rarely) this:
>
> | [] Waiting for /dev to be fully populated...
> | =
> | [ BUG: udevd/229 still has locks held! ]
> |
Since we replaced msleep() by hrtimer I see now and then (rarely) this:
| [] Waiting for /dev to be fully populated...
| =
| [ BUG: udevd/229 still has locks held! ]
| 3.12.11-rt17 #23 Not tainted
| -
| 1 lock held by
Since we replaced msleep() by hrtimer I see now and then (rarely) this:
| [] Waiting for /dev to be fully populated...
| =
| [ BUG: udevd/229 still has locks held! ]
| 3.12.11-rt17 #23 Not tainted
| -
| 1 lock held by
On Wed, 19 Feb 2014 12:53:53 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
Since we replaced msleep() by hrtimer I see now and then (rarely) this:
| [] Waiting for /dev to be fully populated...
| =
| [ BUG: udevd/229 still has locks
On 02/19/2014 04:27 PM, Steven Rostedt wrote:
Hmm, I wonder if this is because msleep() sets the tasks state to
TASK_UNINTERRUPTIBLE, and hrtimer_nanosleep sets it to
TASK_INTERRUPTIBLE.
No, it is because freezable_schedule() is called via do_nanosleep() in
hrtimer call path and msleep()
6 matches
Mail list logo