* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > Instead of that one, i tried CFSv3 and i cannot reproduce the hang
> > anymore, Thanks!...
>
> And that explains why CFS-v3 on 21-rc7-git3 wouldn't show me the hang.
> As a matter of fact, nothing I did showed any bad behavior! Note that
> I was
* Bill Davidsen [EMAIL PROTECTED] wrote:
Instead of that one, i tried CFSv3 and i cannot reproduce the hang
anymore, Thanks!...
And that explains why CFS-v3 on 21-rc7-git3 wouldn't show me the hang.
As a matter of fact, nothing I did showed any bad behavior! Note that
I was doing
S.Çag(lar Onur wrote:
18 Nis 2007 Çar tarihinde, Ingo Molnar s,unlar? yazm?s,t?:
* S.Çag(lar Onur <[EMAIL PROTECTED]> wrote:
- schedule();
+ msleep(1);
which Ingo sends me to try also has the same effect on me. I cannot
reproduce hangs anymore with that patch applied top of CFS
S.Çag(lar Onur wrote:
18 Nis 2007 Çar tarihinde, Ingo Molnar s,unlar? yazm?s,t?:
* S.Çag(lar Onur [EMAIL PROTECTED] wrote:
- schedule();
+ msleep(1);
which Ingo sends me to try also has the same effect on me. I cannot
reproduce hangs anymore with that patch applied top of CFS
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> > great! Could you please unapply the hack above and try the proper
> > fix below, does this one solve the hangs too?
>
> Instead of that one, i tried CFSv3 and i cannot reproduce the hang
> anymore, Thanks!...
cool, thanks for the quick
18 Nis 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
> * S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> > - schedule();
> > + msleep(1);
> >
> > which Ingo sends me to try also has the same effect on me. I cannot
> > reproduce hangs anymore with that patch applied top of CFS while one
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> At this point you might as well call the requeue operation something
> having to do with yield. [...]
agreed - i've just done a requeue_task -> yield_task rename in my tree.
(patch below)
> [...] I also suspect what goes on during the
On Wed, Apr 18, 2007 at 05:48:11PM +0200, Ingo Molnar wrote:
> static void requeue_task_fair(struct rq *rq, struct task_struct *p)
> {
> dequeue_task_fair(rq, p);
> p->on_rq = 0;
> - enqueue_task_fair(rq, p);
> + /*
> + * Temporarily insert at the last position of the
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> - schedule();
> + msleep(1);
> which Ingo sends me to try also has the same effect on me. I cannot
> reproduce hangs anymore with that patch applied top of CFS while one
> console checks out SVN repos and other one compiles a small test
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> Replacing the sched_yield in demux.c with an usleep(10) stopped those
> seeking hangs here (at least I was able to pull the slider back and
> forth during 2 mins without trouble compared to the few secs I need
> earlier to get a hang).
great -
18 Nis 2007 Çar tarihinde, Christoph Pfister şunları yazmıştı:
> Replacing the sched_yield in demux.c with an usleep(10) stopped those
> seeking hangs here (at least I was able to pull the slider back and
> forth during 2 mins without trouble compared to the few secs I need
> earlier to get a
2007/4/18, Christoph Pfister <[EMAIL PROTECTED]>:
[ Sorry for accidentally dropping CCs ]
2007/4/18, Christoph Pfister <[EMAIL PROTECTED]>:
> 2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
> >
> > * Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >
> > > Or I could try playing around a bit with
18 Nis 2007 Çar tarihinde, Christoph Pfister şunları yazmıştı:
> > Okay - so here are some results (it's strange that gdb goes nuts
> > inside the xine_play call). I have three bts (seems to be fairly easy
> > to reproduce that behaviour over here): Twice while playing an audio
> > cd and once
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
> does this:
>
> pthread_mutex_unlock( >demux_lock );
>
> lprintf ("sched_yield\n");
>
> sched_yield();
> pthread_mutex_lock( >demux_lock );
>
> why
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
> > does this:
>
> plus it does this too:
>
> pthread_mutex_unlock( >demux_lock );
> xine_usec_sleep(10);
> pthread_mutex_lock( >demux_lock );
>
> this would
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
> does this:
plus it does this too:
pthread_mutex_unlock( >demux_lock );
xine_usec_sleep(10);
pthread_mutex_lock( >demux_lock );
this would explain the
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c does
this:
pthread_mutex_unlock( >demux_lock );
lprintf ("sched_yield\n");
sched_yield();
pthread_mutex_lock( >demux_lock );
why is this done? CFS has definitely changed the yield
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> It's nearly impossible for me to find out which mutex is deadlocking.
i've disassembled the xine_play function, and here are the function
calls in it:
pthread_mutex_lock()
xine_log()
function pointer call
right after it:
2007/4/18, Christoph Pfister <[EMAIL PROTECTED]>:
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
>
> * Christoph Pfister <[EMAIL PROTECTED]> wrote:
>
> > >which thread would be the most interesting to you - 9324?
> >
> > The thread which should wake the main thread - but hmm ... 9303 seems
> > to
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >which thread would be the most interesting to you - 9324?
>
> The thread which should wake the main thread - but hmm ... 9303 seems
> to be rather dead-locked than doing pthread_cond_timedwait() ?
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >which thread would be the most interesting to you - 9324?
>
> The thread which should wake the main thread - but hmm ... 9303 seems
> to be rather dead-locked than doing pthread_cond_timedwait() ?
ok, here it is, 9303 with better symbol names:
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >are the updated backtraces in the followup mail i just sent more
> >useful? (I still have that stuck session running so i can whatever
> >debugging you'd like to see done.)
>
>
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >are the updated backtraces in the followup mail i just sent more
> >useful? (I still have that stuck session running so i can whatever
> >debugging you'd like to see done.)
>
> QWidget::setUpdatesEnabled() is (wrongly) present in every thread
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >backtrace:
> >
> > #0 0xe410 in __kernel_vsyscall ()
> > #1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib/libpthread.so.0
> > #2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from
On Wed, 2007-04-18 at 11:01 +0200, Ingo Molnar wrote:
> * Christoph Pfister <[EMAIL PROTECTED]> wrote:
>
> > >backtrace:
> > >
> > > #0 0xe410 in __kernel_vsyscall ()
> > > #1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > > /lib/libpthread.so.0
> > > #2 0xb79fd1a8 in
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> these were only the threads that showed up in htop. Here's a full
> analysis about what all threads are doing:
>
> Process 9303: stuck in xine_play()/pthread_mutex_lock()
> Process 9319: stuck in pthread_cond_timedwait()
> Process 9320: stuck in
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >backtrace:
> >
> > #0 0xe410 in __kernel_vsyscall ()
> > #1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib/libpthread.so.0
> > #2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from /usr/lib/libxine.so.1
> > #3 0xb7a030ab in
Hi,
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >> > [1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
>
> Could you
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> update: i've reproduced one kind of a hang but i'm not sure it's the
> same hang Ismail is seeing. It was quite hard to trigger it under CFS,
> i had to do wild forward/backward button seeks on a real DVD and i
> mixed it with CPU-intense workloads
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >> > [1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
>
> Could you try xine-ui or gxine? Because I suspect rather
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister [EMAIL PROTECTED] wrote:
[1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
Could you try xine-ui or gxine? Because I suspect rather xine-lib
Hi,
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister [EMAIL PROTECTED] wrote:
[1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
Could you try
* Ingo Molnar [EMAIL PROTECTED] wrote:
update: i've reproduced one kind of a hang but i'm not sure it's the
same hang Ismail is seeing. It was quite hard to trigger it under CFS,
i had to do wild forward/backward button seeks on a real DVD and i
mixed it with CPU-intense workloads on the
* Christoph Pfister [EMAIL PROTECTED] wrote:
backtrace:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from /usr/lib/libxine.so.1
#3 0xb7a030ab in
* Ingo Molnar [EMAIL PROTECTED] wrote:
these were only the threads that showed up in htop. Here's a full
analysis about what all threads are doing:
Process 9303: stuck in xine_play()/pthread_mutex_lock()
Process 9319: stuck in pthread_cond_timedwait()
Process 9320: stuck in
On Wed, 2007-04-18 at 11:01 +0200, Ingo Molnar wrote:
* Christoph Pfister [EMAIL PROTECTED] wrote:
backtrace:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0xb79fd1a8 in QWidget::setUpdatesEnabled ()
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
backtrace:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from
* Christoph Pfister [EMAIL PROTECTED] wrote:
are the updated backtraces in the followup mail i just sent more
useful? (I still have that stuck session running so i can whatever
debugging you'd like to see done.)
QWidget::setUpdatesEnabled() is (wrongly) present in every thread
except
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
are the updated backtraces in the followup mail i just sent more
useful? (I still have that stuck session running so i can whatever
debugging you'd like to see done.)
QWidget::setUpdatesEnabled() is
* Christoph Pfister [EMAIL PROTECTED] wrote:
which thread would be the most interesting to you - 9324?
The thread which should wake the main thread - but hmm ... 9303 seems
to be rather dead-locked than doing pthread_cond_timedwait() ?
ok, here it is, 9303 with better symbol names:
#0
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
which thread would be the most interesting to you - 9324?
The thread which should wake the main thread - but hmm ... 9303 seems
to be rather dead-locked than doing pthread_cond_timedwait() ?
ok, here it
2007/4/18, Christoph Pfister [EMAIL PROTECTED]:
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
which thread would be the most interesting to you - 9324?
The thread which should wake the main thread - but hmm ... 9303 seems
to be rather
* Christoph Pfister [EMAIL PROTECTED] wrote:
It's nearly impossible for me to find out which mutex is deadlocking.
i've disassembled the xine_play function, and here are the function
calls in it:
unresolved widget call?
pthread_mutex_lock()
xine_log()
unresolved widget call?
function
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c does
this:
pthread_mutex_unlock( stream-demux_lock );
lprintf (sched_yield\n);
sched_yield();
pthread_mutex_lock( stream-demux_lock );
why is this done? CFS has definitely changed the yield
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
does this:
plus it does this too:
pthread_mutex_unlock( stream-demux_lock );
xine_usec_sleep(10);
pthread_mutex_lock( stream-demux_lock );
this would explain the
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
does this:
plus it does this too:
pthread_mutex_unlock( stream-demux_lock );
xine_usec_sleep(10);
pthread_mutex_lock( stream-demux_lock );
this would
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
does this:
pthread_mutex_unlock( stream-demux_lock );
lprintf (sched_yield\n);
sched_yield();
pthread_mutex_lock( stream-demux_lock );
why is
18 Nis 2007 Çar tarihinde, Christoph Pfister şunları yazmıştı:
Okay - so here are some results (it's strange that gdb goes nuts
inside the xine_play call). I have three bts (seems to be fairly easy
to reproduce that behaviour over here): Twice while playing an audio
cd and once while
2007/4/18, Christoph Pfister [EMAIL PROTECTED]:
[ Sorry for accidentally dropping CCs ]
2007/4/18, Christoph Pfister [EMAIL PROTECTED]:
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
Or I could try playing around a bit with your patchset and
18 Nis 2007 Çar tarihinde, Christoph Pfister şunları yazmıştı:
Replacing the sched_yield in demux.c with an usleep(10) stopped those
seeking hangs here (at least I was able to pull the slider back and
forth during 2 mins without trouble compared to the few secs I need
earlier to get a hang).
* Christoph Pfister [EMAIL PROTECTED] wrote:
Replacing the sched_yield in demux.c with an usleep(10) stopped those
seeking hangs here (at least I was able to pull the slider back and
forth during 2 mins without trouble compared to the few secs I need
earlier to get a hang).
great -
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
- schedule();
+ msleep(1);
which Ingo sends me to try also has the same effect on me. I cannot
reproduce hangs anymore with that patch applied top of CFS while one
console checks out SVN repos and other one compiles a small test
On Wed, Apr 18, 2007 at 05:48:11PM +0200, Ingo Molnar wrote:
static void requeue_task_fair(struct rq *rq, struct task_struct *p)
{
dequeue_task_fair(rq, p);
p-on_rq = 0;
- enqueue_task_fair(rq, p);
+ /*
+ * Temporarily insert at the last position of the tree:
+
* William Lee Irwin III [EMAIL PROTECTED] wrote:
At this point you might as well call the requeue operation something
having to do with yield. [...]
agreed - i've just done a requeue_task - yield_task rename in my tree.
(patch below)
[...] I also suspect what goes on during the timer tick
18 Nis 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
- schedule();
+ msleep(1);
which Ingo sends me to try also has the same effect on me. I cannot
reproduce hangs anymore with that patch applied top of CFS while one
console
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
great! Could you please unapply the hack above and try the proper
fix below, does this one solve the hangs too?
Instead of that one, i tried CFSv3 and i cannot reproduce the hang
anymore, Thanks!...
cool, thanks for the quick turnaround!
15 Nis 2007 Paz tarihinde, Christoph Pfister şunları yazmıştı:
> Could you try xine-ui or gxine? Because I suspect rather xine-lib for
> freezing issues. In any way I think a gdb backtrace would be much
> nicer - but if you can't reproduce the freeze issue with other xine
> based players and want
Hi,
2007/4/15, Ingo Molnar <[EMAIL PROTECTED]>:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > [1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
Could you try xine-ui or gxine? Because I suspect rather xine-lib for
freezing issues. In any way I think a gdb backtrace would be much
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > [1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
>
> thanks. This does has the appearance of a userspace race condition of
> some sorts. Can you trigger this hang with the patch below applied to
> the vanilla tree as well? (with no CFS
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> > hm, could you try to strace it and/or attach gdb to it and figure
> > out what's wrong? (perhaps involving the Kaffeine developers too?)
> > As long as it's not a kernel level crash i cannot see how the
> > scheduler could directly cause this -
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
hm, could you try to strace it and/or attach gdb to it and figure
out what's wrong? (perhaps involving the Kaffeine developers too?)
As long as it's not a kernel level crash i cannot see how the
scheduler could directly cause this - other than
* Ingo Molnar [EMAIL PROTECTED] wrote:
[1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
thanks. This does has the appearance of a userspace race condition of
some sorts. Can you trigger this hang with the patch below applied to
the vanilla tree as well? (with no CFS patch
Hi,
2007/4/15, Ingo Molnar [EMAIL PROTECTED]:
* Ingo Molnar [EMAIL PROTECTED] wrote:
[1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
Could you try xine-ui or gxine? Because I suspect rather xine-lib for
freezing issues. In any way I think a gdb backtrace would be much
nicer -
15 Nis 2007 Paz tarihinde, Christoph Pfister şunları yazmıştı:
Could you try xine-ui or gxine? Because I suspect rather xine-lib for
freezing issues. In any way I think a gdb backtrace would be much
nicer - but if you can't reproduce the freeze issue with other xine
based players and want to
64 matches
Mail list logo
