<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [G84] nouveau fails to properly initialize GPU" href="https://bugs.freedesktop.org/show_bug.cgi?id=82714#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [G84] nouveau fails to properly initialize GPU" href="https://bugs.freedesktop.org/show_bug.cgi?id=82714">bug 82714</a> from <a class="email" href="mailto:bonbons@sysophe.eu" title="Bruno <bonbons@sysophe.eu>"> Bruno</a> <pre>Created <a href="attachment.cgi?id=114730" name="attach_114730" title="dmesg with 3.19">attachment 114730</a> <a href="attachment.cgi?id=114730&action=edit" title="dmesg with 3.19">[details]</a> dmesg with 3.19 Sorry for rather late reply, so no issue you being slow too. (In reply to Pierre Moreau from <a href="show_bug.cgi?id=82714#c6">comment #6</a>) > 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 <a href="show_bug.cgi?id=82714#c5">comment #5</a>) > > After fresh boot: > > echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/reset > > Does adding an `echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/rescan` after > the reset changes something? Seen no change in behavior. > You hit some PFIFO interrupt 0x00200000... Btw, which kernel version was > this log taken from? Should have been 3.18 looking at the bug history. > Could you please take another log using the reset/rescan trick with nouveau.debug=debug? > The debug argument of Nouveau takes a string (allowed values are "fatal", > "error", "warn", "info", "debug", "trace", "paranoia" and "spam"), > so your 0xff didn't worked. Retried with `modprobe nouveau debug=debug` Full dmesg attached. > It's likely that the PFIFO interrupt is unrelated to the "unable to handle > kernel paging request" problem, so you should consider opening a new bug > report for it. As previously, no (real) badness by just modprobing nouveau. Starting Xorg on top of it (though while having other Xorg running on radeon, but from local linux console) gets my a stuck Xorg: [<ffffffff815704ac>] rpm_resume+0x18c/0x5c0 [<ffffffff81570928>] __pm_runtime_resume+0x48/0x70 [<ffffffffa00914af>] nouveau_drm_open+0x3f/0x230 [nouveau] [<ffffffff8144123d>] drm_open+0x1ad/0x4b0 [<ffffffff81447711>] drm_stub_open+0xb1/0x130 [<ffffffff811c6371>] chrdev_open+0xb1/0x190 [<ffffffff811bf702>] do_dentry_open.isra.18+0x1f2/0x320 [<ffffffff811bf8a1>] vfs_open+0x41/0x50 [<ffffffff811cd056>] do_last.isra.59+0x266/0xf20 [<ffffffff811d0329>] path_openat+0x89/0x5a0 [<ffffffff811d18ae>] do_filp_open+0x3e/0xa0 [<ffffffff811c0eee>] do_sys_open+0x12e/0x230 [<ffffffff811c1009>] SyS_open+0x19/0x20 [<ffffffff81861252>] system_call_fastpath+0x12/0x17 [<ffffffffffffffff>] 0xffffffffffffffff That Xorg's log is rather boring with 55 lines ending with: [ 835.442] (==) ModulePath set to "/usr/lib64/xorg/modules" [ 835.442] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 835.442] (II) Loader magic: 0x812c80 [ 835.442] (II) Module ABI versions: [ 835.442] X.Org ANSI C Emulation: 0.4 [ 835.442] X.Org Video Driver: 18.0 [ 835.442] X.Org XInput driver : 21.0 [ 835.442] X.Org Server Extension : 8.0 [ 835.443] (II) xfree86: Adding drm device (/dev/dri/card0) [ 835.444] (II) xfree86: Adding drm device (/dev/dri/card1) >From Xorg's kernel-side stack it looks stuck in runtime-PM. Will retry with runpm=0 for safety... (and then also with 4.0-rc6)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>