similar to: [Bug 82714] [G84] nouveau fails to properly initialize GPU

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|nouveau: fails to properly |[G84] nouveau fails to |initialize GPU |properly initialize GPU -- You are

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #21 from Pierre Moreau <pierre.morrow at free.fr> --- I tested with latest Nouveau and latest drm-next as of yesterday (4.6-rcX), with the G84 alongside a GM206; the GM206 was the one driving the screen. Launching weston or kmscon works, but starting X makes the whole computer freeze (no responce on key presses, power button

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #22 from Pierre Moreau <pierre.morrow at free.fr> --- And using the G84 for driving the screen results in the display receiving no signal from the GPU (over VGA (using a VGA->DVI adapter) or HDMI). In the logs, the card did found the screen and initialised a fb of the correct resolution; they are no errors to be found.

Hi there, Could someone please comment on the following hard-lock (*). Staring at the code, I see `nvkm_rd32` calls are enclosed in a timeout detection, except one. drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171 ... nvkm_msec(device, 2000, if (!(nvkm_rd32(device, 0x100c80) & 0x00000001)) break; ); ... Would it make sense to also enclose this in the do/while loop ? Full ref: *

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Resolution|--- |FIXED --- Comment #2 from Pierre Moreau

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Bruno <bonbons67 at internet.lu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #3 from Bruno <bonbons67 at

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #4 from Pierre Moreau <pierre.morrow at free.fr> --- (In reply to Bruno from comment #3) > Are you testing on a system where the GeForce 8600 GTS is a secondary GPU > and not initialized by VBIOS? I wasn't, you're right. I'll plug my HD6870 along and see if I can debug this. Does it only go wrong when

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #6 from Pierre Moreau <pierre.morrow at free.fr> --- Sorry, I didn't had much time to look into it... I'm currently tracking some similar problems on my G96, which is a secondary GPU. Hopefully, if I manage to solve it, the patch will help you too. (In reply to Bruno from comment #5) > After fresh boot: > echo 1

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #8 from Bruno <bonbons at sysophe.eu> --- Created attachment 114731 --> https://bugs.freedesktop.org/attachment.cgi?id=114731&action=edit dmesg with 3.19 but runpm=0 Same kernel, kernel log starting at loading nouveau with `modprobe nouveau debug=debug runpm=0` and running Xorg on top of it: Xorg.0.log tail: [

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #9 from Bruno <bonbons at sysophe.eu> --- Created attachment 114735 --> https://bugs.freedesktop.org/attachment.cgi?id=114735&action=edit 4.0-rc6 dmesg of nouveau loading (debug, runpm=0) 4.0-rc6 is even worse as it dies shortly after modprobing nouveau (even before I have the opportunity to launch Xorg). Results are

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #23 from Pierre Moreau <pierre.morrow at free.fr> --- s/they are no/there are no --" -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=82714 Martin Peres <martin.peres at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #25 from Martin Peres

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #10 from Bruno <bonbons at sysophe.eu> --- (In reply to Bruno from comment #9) > Created attachment 114735 [details] > 4.0-rc6 dmesg of nouveau loading (debug, runpm=0) The first BUG happens in evo_wait() at line 420 of nv50_display.c Seems like dmac->ptr[put] is bad. 413: evo_wait(void *evoc, int nr) 414: { 415:

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #7 from Bruno <bonbons at sysophe.eu> --- Created attachment 114730 --> https://bugs.freedesktop.org/attachment.cgi?id=114730&action=edit dmesg with 3.19 Sorry for rather late reply, so no issue you being slow too. (In reply to Pierre Moreau from comment #6) > Sorry, I didn't had much time to look into it...

Hi, I've encountered a severe regression in TU116 (probably also TU117) introduced in 5.3-rc4 (valid also for recent 5.4.2) [1]. The system usually hangs on the subsequent graphic mode related operation (calling xrandr after login is enough) with the following error: > kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] ... > kernel: nouveau 0000:01:00.0: DRM: failed to idle channel

https://bugs.freedesktop.org/show_bug.cgi?id=112239 Bug ID: 112239 Summary: nouveau hangs video with TU116 - regression in kernel 5.3 Product: xorg Version: 7.7 (2012.06) Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component:

Hi Marcin, You should do a git bisect rather than guessing about commits. I suspect that searching for "kernel git bisect fedora" should prove instructive if you're not sure how to do this. Cheers, -ilia On Mon, Dec 16, 2019 at 11:42 AM Marcin Zaj?czkowski <mszpak at wp.pl> wrote: > > Hi, > > I've encountered a severe regression in TU116 (probably also

https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #5 from Bruno <bonbons67 at internet.lu> --- After fresh boot: echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/reset Kernel log for modprobe nouveau debug=0xff: 2014-12-13 18:55:58.978720 +0100 [ 108.870465] nouveau 0000:01:00.0: enabling device (0004 -> 0007) 2014-12-13 18:55:58.981262 +0100 [ 108.873035] nouveau [

https://bugs.freedesktop.org/show_bug.cgi?id=105940 Bug ID: 105940 Summary: Display freeze caused by nouveau Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau

The obvious candidate based on a quick scan is 0acf5676dc0ffe0683543a20d5ecbd112af5b8ee -- it merges a fix that messes with PCI stuff, and there lie dragons. You could try building that commit, and if things still work, then I have no idea (and you've narrowed the range). Also I'd recommend ensuring that the good kernel is really good and the bad kernel is really bad -- boot them a few