On 12/11/2015 21:21, Samuel Pitoiset wrote:
On 11/12/2015 08:51 PM, Samuel Pitoiset wrote:
Hi Emil,
On 11/10/2015 04:35 PM, Emil Velikov wrote:
Hi Samuel,
Sorry about this I thought I already replied :-\
On 29 October 2015 at 22:22, Samuel Pitoiset
wrote:
On 10/27/2015 02:01 PM, samuel
On 11/12/2015 08:51 PM, Samuel Pitoiset wrote:
Hi Emil,
On 11/10/2015 04:35 PM, Emil Velikov wrote:
Hi Samuel,
Sorry about this I thought I already replied :-\
On 29 October 2015 at 22:22, Samuel Pitoiset
wrote:
On 10/27/2015 02:01 PM, samuel.pitoiset wrote:
On 27/10/2015 12:52, Emil Vel
Hi Emil,
On 11/10/2015 04:35 PM, Emil Velikov wrote:
Hi Samuel,
Sorry about this I thought I already replied :-\
On 29 October 2015 at 22:22, Samuel Pitoiset wrote:
On 10/27/2015 02:01 PM, samuel.pitoiset wrote:
On 27/10/2015 12:52, Emil Velikov wrote:
On 27 October 2015 at 10:50, samuel.
Hi Samuel,
Sorry about this I thought I already replied :-\
On 29 October 2015 at 22:22, Samuel Pitoiset wrote:
> On 10/27/2015 02:01 PM, samuel.pitoiset wrote:
>> On 27/10/2015 12:52, Emil Velikov wrote:
>>>
>>> On 27 October 2015 at 10:50, samuel.pitoiset
>>> wrote:
On 27/10/2015 11
On 10/27/2015 02:01 PM, samuel.pitoiset wrote:
On 27/10/2015 12:52, Emil Velikov wrote:
On 27 October 2015 at 10:50, samuel.pitoiset
wrote:
On 27/10/2015 11:37, Emil Velikov wrote:
On 22 October 2015 at 00:16, Julien Isorce
wrote:
The real fix is in nouveau_drm_winsys.c by setting dev t
On 27/10/2015 12:52, Emil Velikov wrote:
On 27 October 2015 at 10:50, samuel.pitoiset wrote:
On 27/10/2015 11:37, Emil Velikov wrote:
On 22 October 2015 at 00:16, Julien Isorce
wrote:
The real fix is in nouveau_drm_winsys.c by setting dev to 0.
Which means dev's ownership has been passed t
On 27 October 2015 at 10:50, samuel.pitoiset wrote:
> On 27/10/2015 11:37, Emil Velikov wrote:
>>
>> On 22 October 2015 at 00:16, Julien Isorce
>> wrote:
>>>
>>> The real fix is in nouveau_drm_winsys.c by setting dev to 0.
>>> Which means dev's ownership has been passed to previous call.
>>> Othe
On 27/10/2015 11:37, Emil Velikov wrote:
On 22 October 2015 at 00:16, Julien Isorce wrote:
The real fix is in nouveau_drm_winsys.c by setting dev to 0.
Which means dev's ownership has been passed to previous call.
Other changes are there to be consistent with what the
screen_create functions
On 22 October 2015 at 00:16, Julien Isorce wrote:
> The real fix is in nouveau_drm_winsys.c by setting dev to 0.
> Which means dev's ownership has been passed to previous call.
> Other changes are there to be consistent with what the
> screen_create functions already do on errors.
>
> Encountered
On 25 October 2015 at 21:56, Samuel Pitoiset
wrote:
>
>
> On 10/22/2015 01:16 AM, Julien Isorce wrote:
>
>> The real fix is in nouveau_drm_winsys.c by setting dev to 0.
>> Which means dev's ownership has been passed to previous call.
>> Other changes are there to be consistent with what the
>> sc
On 10/22/2015 01:16 AM, Julien Isorce wrote:
The real fix is in nouveau_drm_winsys.c by setting dev to 0.
Which means dev's ownership has been passed to previous call.
Other changes are there to be consistent with what the
screen_create functions already do on errors.
This actually happens be
The real fix is in nouveau_drm_winsys.c by setting dev to 0.
Which means dev's ownership has been passed to previous call.
Other changes are there to be consistent with what the
screen_create functions already do on errors.
Encountered this crash because nvc0_screen_create sometimes fails with:
nv
12 matches
Mail list logo
