On Thu, Feb 26, 2015 at 5:02 AM, Mike Galbraith
wrote:
> On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
>
>> The deadlock returned after I applied this patch in v3.18.7-rt2.
>
> Grr, because dummy here munged a reject when he backported to 3.18-rt.
> Please try the below, my trusty
On Thu, 2015-02-26 at 11:53 +0100, Sebastian Andrzej Siewior wrote:
> 4.0-rt? So you are a time traveler?
Nah, I just didn't want to stop at 3.18, so rolled forward to master.
When Linus switched to 4.0, I didn't have to do anything other than to
change the directory name :) If you're
* Mike Galbraith | 2015-02-26 09:02:05 [+0100]:
>I found what was breaking my core2 lappy in 4.0-rt as well, namely the
4.0-rt? So you are a time traveler?
>locking, ww_mutex: fix ww_mutex vs self-deadlock
>
>If the caller already holds the mutex, task_blocks_on_rt_mutex()
>returns -EDEADLK, we
On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
> The deadlock returned after I applied this patch in v3.18.7-rt2.
Grr, because dummy here munged a reject when he backported to 3.18-rt.
Please try the below, my trusty old Q6600 box is now running with
nouveau/drm in both 3.18-rt
On Thu, Feb 26, 2015 at 5:02 AM, Mike Galbraith
umgwanakikb...@gmail.com wrote:
On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
The deadlock returned after I applied this patch in v3.18.7-rt2.
Grr, because dummy here munged a reject when he backported to 3.18-rt.
Please try the
On Thu, 2015-02-26 at 11:53 +0100, Sebastian Andrzej Siewior wrote:
4.0-rt? So you are a time traveler?
Nah, I just didn't want to stop at 3.18, so rolled forward to master.
When Linus switched to 4.0, I didn't have to do anything other than to
change the directory name :) If you're
* Mike Galbraith | 2015-02-26 09:02:05 [+0100]:
I found what was breaking my core2 lappy in 4.0-rt as well, namely the
4.0-rt? So you are a time traveler?
locking, ww_mutex: fix ww_mutex vs self-deadlock
If the caller already holds the mutex, task_blocks_on_rt_mutex()
returns -EDEADLK, we
On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
The deadlock returned after I applied this patch in v3.18.7-rt2.
Grr, because dummy here munged a reject when he backported to 3.18-rt.
Please try the below, my trusty old Q6600 box is now running with
nouveau/drm in both 3.18-rt and
On Tue, 2015-02-24 at 17:00 -0300, Gustavo Bittencourt wrote:
> Is there anyway that I could help? I think I can write a code to
> reproduce the deadlock without the nouveau driver.
A non-drm testcase would be nice. The people who decided that serial
ports could just _go away_ should be pelted
On Tue, Feb 24, 2015 at 2:50 PM, Mike Galbraith
wrote:
> On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
>>
>> The deadlock returned after I applied this patch in v3.18.7-rt2. Here is my
>> log:
>
>
> Hrmph. I definitely want your patch to die ;-) It adds a whole new
> dimension
On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
> On Tue, Feb 24, 2015 at 10:41 AM, Mike Galbraith
> wrote:
> > locking, ww_mutex: fix ww_mutex vs self-deadlock
> >
> > If the caller already holds the mutex, task_blocks_on_rt_mutex()
> > returns -EDEADLK, we proceed directly to
On Tue, Feb 24, 2015 at 10:41 AM, Mike Galbraith
wrote:
> locking, ww_mutex: fix ww_mutex vs self-deadlock
>
> If the caller already holds the mutex, task_blocks_on_rt_mutex()
> returns -EDEADLK, we proceed directly to rt_mutex_handle_deadlock()
> where it's instant game over.
>
> Let ww_mutexes
On Tue, 2015-02-24 at 14:41 +0100, Mike Galbraith wrote:
> On Mon, 2015-02-23 at 10:06 +0100, Sebastian Andrzej Siewior wrote:
>
> > - a patch to properly use the rtmutex deadlock detector in ww-mutex
> > which seems to cure a nouveau deadlock (Gustavo Bittencourt)
>
> How about the below
On Mon, 2015-02-23 at 10:06 +0100, Sebastian Andrzej Siewior wrote:
> - a patch to properly use the rtmutex deadlock detector in ww-mutex
> which seems to cure a nouveau deadlock (Gustavo Bittencourt)
How about the below instead. In 4.0.0-rt, i915 deadlocked, and the
below fixed that. DRM
On Tue, Feb 24, 2015 at 2:50 PM, Mike Galbraith
umgwanakikb...@gmail.com wrote:
On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
The deadlock returned after I applied this patch in v3.18.7-rt2. Here is my
log:
Hrmph. I definitely want your patch to die ;-) It adds a whole
On Mon, 2015-02-23 at 10:06 +0100, Sebastian Andrzej Siewior wrote:
- a patch to properly use the rtmutex deadlock detector in ww-mutex
which seems to cure a nouveau deadlock (Gustavo Bittencourt)
How about the below instead. In 4.0.0-rt, i915 deadlocked, and the
below fixed that. DRM
On Tue, 2015-02-24 at 14:41 +0100, Mike Galbraith wrote:
On Mon, 2015-02-23 at 10:06 +0100, Sebastian Andrzej Siewior wrote:
- a patch to properly use the rtmutex deadlock detector in ww-mutex
which seems to cure a nouveau deadlock (Gustavo Bittencourt)
How about the below instead. In
On Tue, Feb 24, 2015 at 10:41 AM, Mike Galbraith
umgwanakikb...@gmail.com wrote:
locking, ww_mutex: fix ww_mutex vs self-deadlock
If the caller already holds the mutex, task_blocks_on_rt_mutex()
returns -EDEADLK, we proceed directly to rt_mutex_handle_deadlock()
where it's instant game over.
On Tue, 2015-02-24 at 13:19 -0300, Gustavo Bittencourt wrote:
On Tue, Feb 24, 2015 at 10:41 AM, Mike Galbraith
umgwanakikb...@gmail.com wrote:
locking, ww_mutex: fix ww_mutex vs self-deadlock
If the caller already holds the mutex, task_blocks_on_rt_mutex()
returns -EDEADLK, we proceed
On Tue, 2015-02-24 at 17:00 -0300, Gustavo Bittencourt wrote:
Is there anyway that I could help? I think I can write a code to
reproduce the deadlock without the nouveau driver.
A non-drm testcase would be nice. The people who decided that serial
ports could just _go away_ should be pelted
20 matches
Mail list logo
