https://bugs.freedesktop.org/show_bug.cgi?id=98852
--- Comment #13 from Martin Peres ---
(In reply to Egon Niessner from comment #12)
> I did some further tests with setting of the boot time parameter
> in the yast kernel parameter line.
>
> Also with
>
>
The proper fix would have been to select LEDS_CLASS but this can lead
to a circular dependency, as found out by Arnd.
This patch implements Arnd's suggestion instead, at the cost of some
auto-magic for a fringe feature.
Cc: # 4.9.x-
Reported-by: Arnd Bergmann
On 07/12/16 05:32, Martin Peres wrote:
This fixes the auto-magic detection of LEDS_CLASS by fixing the case
where nouveau would be built-in and the LEDS_CLASS would be built as
as module.
Cc: # 4.9.x-
Reported-by: Intel's 0-DAY
Signed-off-by: Martin Peres
This fixes the auto-magic detection of LEDS_CLASS by fixing the case
where nouveau would be built-in and the LEDS_CLASS would be built as
as module.
Cc: # 4.9.x-
Reported-by: Intel's 0-DAY
Signed-off-by: Martin Peres
---
https://bugs.freedesktop.org/show_bug.cgi?id=94727
--- Comment #8 from Ilia Mirkin ---
OK, well staring at the code didn't do me much good.
bkref == NULL means that the pushbuf thing doesn't know about the bo we're
trying to reloc. However just a few lines above in
https://bugs.freedesktop.org/show_bug.cgi?id=94727
Ilia Mirkin changed:
What|Removed |Added
Summary|nouveau/pushbuf.c:238: |[NV30/NV40]
https://bugs.freedesktop.org/show_bug.cgi?id=91954
--- Comment #11 from Martin Peres ---
We are trying to push in DRM link-status that will allow the userspace to react
to errors like this.
I may be convinced to add support for this in Nouveau-drm and -nouveau, since I