similar to: [Bug 40884] Nouveau's TODO list for new comers

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