Nouveau - Mar 2015 - [Bug 82714] [G84] nouveau fails to properly initialize GPU

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...
> 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 > /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)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150330/00d51c19/attachment.html>