Displaying 20 results from an estimated 60000 matches similar to: "[Bug 40884] Nouveau's TODO list for new comers"
2013 Aug 18
0
[Bug 40884] Nouveau's TODO list for new comers
https://bugs.freedesktop.org/show_bug.cgi?id=40884
Bug 40884 depends on bug 40888, which changed state.
Bug 40888 Summary: Implementation of OpenCL on Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=40888
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW
2013 Aug 19
0
[Bug 40884] Nouveau's TODO list for new comers
https://bugs.freedesktop.org/show_bug.cgi?id=40884
Bug 40884 depends on bug 40892, which changed state.
Bug 40892 Summary: Power management
https://bugs.freedesktop.org/show_bug.cgi?id=40892
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
2013 Aug 19
0
[Bug 40884] Nouveau's TODO list for new comers
https://bugs.freedesktop.org/show_bug.cgi?id=40884
Ilia Mirkin <imirkin at alum.mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Ilia Mirkin <imirkin at
2011 Sep 14
2
[Bug 40886] New: Improve our lockup detection, reporting and recovery
https://bugs.freedesktop.org/show_bug.cgi?id=40886
Summary: Improve our lockup detection, reporting and recovery
Product: xorg
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
AssignedTo: nouveau at lists.freedesktop.org
2014 Aug 04
2
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
> It'a pain to deal with gpu reset.
Yeah, well that's nothing new.
> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup.
> But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called
2014 Aug 04
0
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Hey,
op 04-08-14 13:57, Christian K?nig schreef:
> Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
>> op 04-08-14 10:36, Christian K?nig schreef:
>>> Hi Maarten,
>>>
>>> Sorry for the delay. I've got way to much todo recently.
>>>
>>> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>>>> On 01-08-14 18:35, Christian K?nig
2014 Aug 04
2
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
> op 04-08-14 10:36, Christian K?nig schreef:
>> Hi Maarten,
>>
>> Sorry for the delay. I've got way to much todo recently.
>>
>> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>>> On 01-08-14 18:35, Christian K?nig wrote:
>>>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
2014 Aug 04
2
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Hi Maarten,
Sorry for the delay. I've got way to much todo recently.
Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>
> On 01-08-14 18:35, Christian K?nig wrote:
>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
>>> ---
>>> V1 had a nasty bug breaking gpu lockup
2014 Aug 04
0
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
op 04-08-14 10:36, Christian K?nig schreef:
> Hi Maarten,
>
> Sorry for the delay. I've got way to much todo recently.
>
> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>>
>> On 01-08-14 18:35, Christian K?nig wrote:
>>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at
2014 Aug 01
2
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
> ---
> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
> and kill it during lockup recovery instead.
That looks like the delayed work starts running as soon as we submit a
2019 Jun 19
2
nouveau: DRM: GPU lockup - switching to software fbcon
On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
<sergey.senozhatsky.work at gmail.com> wrote:
>
> On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > dmesg
> >
> > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon
> > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> > nouveau 0000:01:00.0: fifo: runlist 0: scheduled for
2019 Jun 19
0
nouveau: DRM: GPU lockup - switching to software fbcon
On (06/14/19 11:50), Sergey Senozhatsky wrote:
> dmesg
>
> nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon
> nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery
> nouveau 0000:01:00.0: fifo: channel 5: killed
> nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery
>
2019 Jun 14
2
nouveau: DRM: GPU lockup - switching to software fbcon
5.2.0-rc4-next-20190613
dmesg
nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon
nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery
nouveau 0000:01:00.0: fifo: channel 5: killed
nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery
nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery
2019 Jun 19
0
nouveau: DRM: GPU lockup - switching to software fbcon
On (06/19/19 01:20), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> <sergey.senozhatsky.work at gmail.com> wrote:
> >
> > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > dmesg
> > >
> > > nouveau 0000:01:00.0: DRM: GPU lockup - switching to software fbcon
> > > nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a
2019 Jun 19
0
nouveau: DRM: GPU lockup - switching to software fbcon
On (06/19/19 02:07), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
> <sergey.senozhatsky.work at gmail.com> wrote:
> >
> > On (06/19/19 01:20), Ilia Mirkin wrote:
> > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > > <sergey.senozhatsky.work at gmail.com> wrote:
> > > >
> > > > On (06/14/19
2019 Jun 19
3
nouveau: DRM: GPU lockup - switching to software fbcon
On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
<sergey.senozhatsky.work at gmail.com> wrote:
>
> On (06/19/19 01:20), Ilia Mirkin wrote:
> > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > <sergey.senozhatsky.work at gmail.com> wrote:
> > >
> > > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > > dmesg
> > > >
2014 Aug 04
2
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
> op 04-08-14 16:37, Christian K?nig schreef:
>>> It'a pain to deal with gpu reset.
>> Yeah, well that's nothing new.
>>
>>> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup.
>>> But this
2014 Jul 31
0
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
---
drivers/gpu/drm/radeon/radeon.h | 3 +
drivers/gpu/drm/radeon/radeon_device.c | 5 +
drivers/gpu/drm/radeon/radeon_fence.c |
2014 Aug 04
2
[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
> op 04-08-14 16:45, Christian K?nig schreef:
>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>>> op 04-08-14 16:37, Christian K?nig schreef:
>>>>> It'a pain to deal with gpu reset.
>>>> Yeah, well that's nothing new.
>>>>
>>>>> I've now tried other solutions
2014 Jul 23
2
[PATCH 09/17] drm/radeon: use common fence implementation for fences
> Regardless of the fence implementation, why would it be a good idea to do a full lockup recovery when some other driver is
> calling your wait function? That doesn't seem to be a nice thing to do, so I think a timeout is the best error you could return here,
> other drivers have to deal with that anyway.
The problem is that we need to guarantee that the lockup will be
resolved