Does it work fine on a cold boot, but only fails on a warm boot? (Is that what
you mean by "after rebooting"?)
(In reply to Ilia Mirkin from comment #1)
> Does it work fine on a cold boot, but only fails on a warm boot? (Is that
> what you mean by "after rebooting"?)

No, its never working...
Ok, md5sums are correct, so your firmware is not corrupted.

I will try to reproduce on the same setup as you (GTX970/4.6-rc4) - can you
confirm that you are using pure 4.6-rc4 without any extra patch? Also, can you
run

$ cat /proc/config.gz >config.gz

and attach the created config.gz file?

Thanks!
(In reply to Alexandre Courbot from comment #8)
> Ok, md5sums are correct, so your firmware is not corrupted.
> 
> I will try to reproduce on the same setup as you (GTX970/4.6-rc4) - can you
> confirm that you are using pure 4.6-rc4 without any extra patch? Also, can
> you run
> 
> $ cat /proc/config.gz >config.gz
> 
> and attach the created config.gz file?
> 
> Thanks!

Yes, its a clean 4.6-rc4, from kernel.org.

I Post the .config in 10h.
Created attachment 123065 [details]
Config File

The .config File.
Successfully booted with your config on 4.6-rc4 and a GM206 (GTX 960). I am
trying to get my hands on a GTX970 to see if this is specific to the card.

Are you able/willing to compile custom Nouveau modules in order to get more
debug information?
This line in the log looks kinda suspicious to me:

[    2.278551] nouveau 0000:01:00.0: enabling device (0000 -> 0003)

I am not seeing it on my end ; could this mean that the Geforce card is a
secondary display device, and that the integrated Intel graphics is the main
one?

In this case maybe you need this patch, which is not in -rc4:
https://lists.freedesktop.org/archives/nouveau/2016-April/024523.html

Also I am surprised by the report that the screen goes blank after this -
failure to initialize GR should not interfere with the ability to display a
framebuffer (only acceleration will be disabled).

Let's make another experiment: can you move /lib/firmware/nvidia/gm204
somewhere else, reboot (you will see a complain about missing firmware files in
the boot log), and tell us whether the display is active after that?

Thanks!
Yes, iam booting with intel-gpu and nvidia-gtx970 card activated. There is a
picture on the intel screen. If i disable the intel gpu in the bios, there is
no output on the nvidia screen.

I try to ssh to the machine, with disabled intel-gpu.

I have a modiefied Bios in the GTX970. Could this be the answer? I disabled the
Fan on the gtx970 under 50C. But everything works on Windows10 and kernel 4.5.0
with nouvau driver.
I removed the /lib/firmware directory, still black screen.
Created attachment 123096 [details]
sys.log after booting with nvidia gtx970 only
Hi,

Your latest comments seem to indicate that the issue is not related to firmware
- it just happens to manifest itself at this stage as well when firmware is
loaded.

2 things to try:

1) Can you try loading Nouveau with the "config=NvForcePost=1" option? Adding
"nouveau.config=NvForcePost=1" to your kernel command line should do it.

2) Can I get a full log of you booting with the /lib/firmware directory
removed, or can you confirm that when you can see Nouveau complaining about the
firmware when you boot in this configuration?

Thanks!
Created attachment 123172 [details]
Logout with msi kernel bug
Created attachment 123173 [details]
logout 2
Created attachment 123174 [details]
logout 3
Created attachment 123175 [details]
Logout1
Created attachment 123176 [details]
Logout2
Created attachment 123177 [details]
Logout3
Created attachment 123178 [details]
/lib/firmware moved, bootlog
Hi,

Not sure why you enabled MSI - I asked if you could set NvForcePost, not NvMSI?
Or maybe you posted on the wrong bug?

My gut feeling is more and more that for some reason devinit is not ran by the
bios and the heuristic in 4.6 does not detect this (which is why I wanted to
try NvForcePost). If you are compiling your own kernel, could you try applying
the following patch and see if things are improving?

https://lists.freedesktop.org/archives/nouveau/2016-April/024523.html
(In reply to Alexandre Courbot from comment #24)
> Hi,
> 
> Not sure why you enabled MSI - I asked if you could set NvForcePost, not
> NvMSI? Or maybe you posted on the wrong bug?
> 
> My gut feeling is more and more that for some reason devinit is not ran by
> the bios and the heuristic in 4.6 does not detect this (which is why I
> wanted to try NvForcePost). If you are compiling your own kernel, could you
> try applying the following patch and see if things are improving?
> 
> https://lists.freedesktop.org/archives/nouveau/2016-April/024523.html

Added Patch and NvForcePost=1 

Result is the Same. I did not enable MSI by bootparamter, it looks like its
enabled by default...
Created attachment 123280 [details]
dmesg after patch
Created attachment 123281 [details]
dmesg after patch, with pcimsi=off
Bug still not solved on new 4.6 KErnel.
Hi,

Ok, so it seems I'm affected too: my desktop with GTX970 doesn't boot kernel
4.6 (comes with recent openSUSE Tumbleweed snapshot release). Although it d=
oes
boot 4.5.4 kernel, from which I'm writing this comment.

I've found this issue by googling "timeout at
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/base.c:145" message from m=
y logs.

Relevant log parts are pretty much identical for me, I can post them here, =
if
needed.=20

Firmware checksums are identical. Haven't tried NvForcePost=3D1 and pci_msi=
=3Doff
yet, will try later if needed.

Anyway, +1 here.

Motherboard: Gigabyte GA-MA770
Videocard: GTX 970 by MSI
UEFI and SecureBoot are enabled.
Created attachment 124715 [details]
dmesg from kernel with debug and NvForcePost=3D1 pci_msi=3Doff

I have only removed a lot of repeated messages from the end (FIFO message
spams), whole beginning was left as is.
Booted the last kernel from tumbleweed with debug on (4.6.2-1).

Firmware MD5's are the same as mentioned.

DMESG output posted above, as mentioned I left the beginning intact, but cu=
tted
rest off due to file being very large (65 MB, it never stops spamming the f=
ifo
message).

If you'll need more info / something specific, just mention it, will follow=
 the
bug.
Comment on attachment 124715 [details]
dmesg from kernel with debug and NvForcePost=3D1 pci_msi=3Doff

- obsolete, wrong kernel parameters
Created attachment 124716 [details]
DMESG with pci_msi=3Doff nouveau.config=3DNvForcePost=3D1 nouveau.debug=3Dt=
race

Sorry, first time nouveau debugging and just realized I completely messed up
the kernel options - this time should be correct.
Created attachment 124724 [=
details]
dmesg for latest linux-next + patches for secboot

Found these patches on the mailing list, thought I could try it out, but no
luck.

https://lists.freedesktop.org/archives/nouveau/2016-June/025336.html<=
/a>

I've appended the dmesg, the kernel source was linux-next as of 2016-06-24 =
with
the patches mentioned applied.
Same symptoms, running either `kernel-4.6.3-300.fc24.x86_64` or
`kernel-4.6.4-301.fc24.x86_64` on Fedora 24.

Do you need some more information from me?
Created attachment 125265 [details]
DMESG with pci_msi=3Doff nouveau.config=3DNvForcePost=3D1 nouveau.debug=3Dt=
race

Asus Z77 and GTX970, it seems the first fifo caused by
https://github.com/torvalds/linux/bl=
ob/master/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/base.c#L142

changing the value to 0x0 allowed the machine to boot, still with lots of
errors.
All 3 users who posted dmesg in this bug have 4GB of VRAM.

Looks like we are narrowing it down. This may be a bug in the =
firmware itself
when dealing with high addresses. Let me check on my side which address the=
 ACR
is loaded, and if I can force a lower address for it.
Tried on a 4GB GM206 / 4.6.4, it passed without any issue:

[   12.410603] nouveau 0000:01:00.0: NVIDIA GM206 (1262f0a1)
[   12.493772] nouveau 0000:01:00.0: bios: version 84.06.01.0c.00
[   12.494306] nouveau 0000:01:00.0: disp: dcb 15 type 8 unknown
[   12.506916] nouveau 0000:01:00.0: fb: 4096 MiB GDDR5
[   12.512991] INST: ffbd5000
[   12.513137]  PGD: ffbcd000
[   12.526018]  WPR: ffba0000
[   12.528160] BLOB: ffbca000
[   12.532053] BLOB: ffbc9000
[   12.532180] [TTM] Zone  kernel: Available graphics memory: 1024460 kiB

... and then I could run glmark2 without any error.

Tried messing with the WPR address to make it invalid and see if I could get
the same error. It happens to be different:

[   31.729804] nouveau 0000:01:00.0: priv: GPC0: 419df4 00000000 (1b40820e)
[   31.729846] nouveau 0000:01:00.0: priv: GPC1: 419df4 00000000 (1b40820e)
[   31.729894] nouveau 0000:01:00.0: priv: GPC0: 505884 c0000000 (1a40820e)
[   31.729924] nouveau 0000:01:00.0: priv: GPC1: 50d884 c0000000 (1a40820e)
[   33.731990] nouveau 0000:01:00.0: timeout at
../drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1469/gf100_gr_init_ctxctl=
()!
[   33.732035] nouveau 0000:01:00.0: gr: init failed, -16

So not sure where this REGION_VIOLATION comes from. Guess I will need to pi=
ng
the fw people at NVIDIA...
I should mention that even though the GR message is the same, =
I am not getting
any REGION_VIOLATION nor timeout in nvkm_secboot_falcon_run() when running
secure boot with an invalid WPR address.
Another interesting experiment would be for someone hitting th=
is to:

- Boot with "nouveau.modeset=3D0 3" on the kernel commandline.
- Suspend the machine with "echo mem > /sys/power/state"
- Resume the machine (there will be no display at this point, so you'll need
ssh access or to type the rest blindly)
- Execute "modprobe nouveau modeset=3D1" and see if the situation=
 is any better.
(In reply to Ben Skeggs from comment #41)
> Another interesting experiment would be for some=
one hitting this to:
>=20
> - Boot with "nouveau.modeset=3D0 3" on the kernel commandlin=
e.
> - Suspend the machine with "echo mem > /sys/power/state"
> - Resume the machine (there will be no display at this point, so you'l=
l need
> ssh access or to type the rest blindly)
> - Execute "modprobe nouveau modeset=3D1" and see if the situ=
ation is any
> better.

Before suspending, also run "modprobe -r nouveau" ;)  (Thanks Ili=
a!)
Got a GTX970/4GB, been able to reproduce the error on the same=
 machine that
booted a GM206/4GB without any issue.
Allocating instmem from the lower VRAM partition (<3.5GB) r=
esults in a
successfull boot. Looks like this is the fix.
Definitely neither rushing nor pestering you but is there an E=
TA for this?
I think Ben mentioned he was working on a fix for this. Ben, d=
o you need more
data from me?
Hi. i5-4670, ASUS H87-pro, Nvidia GTX970. I have the same bug =
on kernel 4.6.*
and on 4.7.0 too. Just black screen on boot... On kernel 4.5.* everything w=
orks
just fine.
(In reply to Ivan from comment #47)
> Hi. i5-4670, ASUS H87-pro, Nvidia GTX970. I have=
 the same bug on kernel
> 4.6.* and on 4.7.0 too. Just black screen on boot... On kernel 4.5.*
> everything works just fine.

Btw. I try to boot Arch Live CD, kernel 4.6.4 with option "nouveau.mod=
eset=3D0"
and it works.
For the record, I had dealt with this problem too, boots fine =
on 4.5.* but not
4.6 (as of today). I have also tried a GTX 960 and a GTX 980 (4GB) (now my
current). Fedora 24 boots fine with each of those cards on 4.6. The EVGA GTX
970 (4GB) did not boot (at all) on kernel 4.6. However it will boot under 4=
.5
but the monitor(s) connected to the 970 card will not work. (I run two card=
s).
Could some kind soul write a how to modify grub2 configs to ad=
d the
`nouveau.modeset=3D0` so we could test is that work on our setup?
(In reply to Yann Golanski from comment #50)
> Could some kind soul write a how to modify grub2=
 configs to add the
> `nouveau.modeset=3D0` so we could test is that work on our setup?

Add it in /boot/grub2/grub.cfg to the kernel commandline for the kernel you
want to boot, or change the boot config inside grub2 for a oneshot (F12). B=
ut
you should have just googled that ;-)
i tested with 'nouveau.modeset=3D0' on kernel 4.5 and 4.6 on d=
ebian/sid and got
the same results of screen flickering and seems like nothing inside of the
nouveau driver getting called.
(In reply to Ilia Guterman from comment #52)
> i tested with 'nouveau.modeset=3D0' on kernel 4.=
5 and 4.6 on debian/sid and got
> the same results of screen flickering and seems like nothing inside of=
 the
> nouveau driver getting called.

Right, `nouveau.modeset=3D0` wont=E2=80=99t prevent Nouveau from loading, h=
owever the
driver is in a "disable" state and won=E2=80=99t do a thing:

> modeset
> Whether the driver should be enabled. 0 for disabled, 1 for enabled, 2=
 for headless

(taken from the Nouveau wiki:
https://nouveau.freedesktop.org/wiki/KernelModuleParameters/#modeset<=
/a>)
(In reply to Ilia Guterman from comment #52)
> i tested with 'nouveau.modeset=3D0' on =
kernel 4.5 and 4.6 on debian/sid and got
> the same results of screen flickering and seems like nothing inside of=
 the
> nouveau driver getting called.

Right, `nouveau.modeset=3D0` wont=E2=80=99t prevent Nouveau from loading, h=
owever the
driver is in a "disable" state and won=E2=80=99t do a thing:

> modeset
> Whether the driver should be enabled. 0 for disabled, 1 for enabled, 2=
 for headless

(taken from the Nouveau wiki:
https://nouveau.freedesktop.org/wiki/Kern=
elModuleParameters/#modeset)
Hi QA:

 I had can to create the manual blacklist entry for nouveau.   I did this
because I wanted to use the non-free driver.  This is also required if you
want to use the Intel HD internal graphics card with a Nvidia chip set as a
secondary card.

The first edit will disable nouveau and verify by "lsmod | grep -i nou=
veau"

Manual edits required to get this working.

1. Created blacklist entry, /etc/modprobe.d/blacklist=C2=ADnouveau.conf as =
shown
below

# cat /etc/modprobe.d/blacklist=C2=ADnouveau.conf

blacklist nouveau

options nouveau modeset=3D0

2. kernel option used, nomodeset

Below (lines below) if you want to use the Nvidia non-free driver support:

3. Used Nvidia xconfig tool, nvidia=C2=ADxconfig

4. Edit the file manually to see what drivers were being used , it should
state: Drivers =E2=80=9Cnvidia=E2=80=9D

5. ** Special note, I have two separate video GPU cards and decided to use
individual heads, device1, device2

Now after booting, Nvidia drivers are working because the X server came up.
I noticed that

'num=C2=ADlock' was off. Verification of X is as follows:

1. Verify what is in proc, lsmod, dmesg messages

# cat /proc/driver/nvidia/version

NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.30 Tue Jul 21 18:53:45
PDT 2015

GCC version: gcc version 4.8.3 20140106 (OpenMandriva Association) (Linaro
GCC 4.8=C2=AD2014.01)

This is the driver we wanted, 352.30, installed from 'mcc'; manual edits
required for the blacklist

file creation. The installation needs to create something. The Nvidia
installer does create a file for

you using their manual installation method by executing the driver
installation <Nvidia-
driver.version>.run.

2. Verify X log in /var/log/Xorg.0.log.

3. Run Nvidia settings and Nvidia System Management Interface tool,
nvidia=C2=ADsettings, a X tool,

and nvidia=C2=ADsmi, System Management interface tool

Nvidia=C2=ADsmi, reports the driver version match such as in
proc/driver/nvidia/version and reports the

GPU(s). GPU=C2=AD0, is the 960; GPU=C2=AD1, is the 730 card. I want to run =
the 960 as
the primary (a

physical connection to a 24in monitor).

# nvidia=C2=ADsmi

Sat Feb 27 04:26:53 2016

+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD+

| NVIDIA=C2=ADSMI 352.30 Driver Version: 352.30 |

|=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD+

| GPU Name Persistence=C2=ADM| Bus=C2=ADId Disp.A | Volatile Uncorr. ECC |

| Fan Temp Perf Pwr:Usage/Cap| Memory=C2=ADUsage | GPU=C2=ADUtil Compute M.=
 |

|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D|

| 0 GeForce GTX 960 Off | 0000:01:00.0 On | N/A |

| 0% 28C P8 7W / 128W | 216MiB / 4091MiB | 0% Default |

+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD+

| 1 GeForce GT 730 Off | 0000:02:00.0 N/A | N/A |

| 30% 28C P8 N/A / N/A | 66MiB / 1023MiB | N/A Default |

+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD+

+=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=
=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=AD=C2=
=AD=C2=AD=C2=AD+

| Processes: GPU Memory |

| GPU PID Type Process name Usage |

|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D|

| 0 4619 G /etc/X11/X 200MiB |

| 0 6121 G /usr/bin/nvidia=C2=ADsettings 2MiB |

| 1 Not Supported |

Regards,

Efrem Mc

PS, I have used this in the past.  You can also try using "acpi_osi=3D=
Linux"
on the kernel command line.
This allows be to boot with the Nvidia card as a primary video source with
the Intel HD graphics card disabled in BIOS.

I have found that the BIOS is disabled and initfs still loads the i915
driver module

On Tue, Aug 9, 2016 at 12:00 PM, <bugzilla-daemon@freedesktop.org> wrote:

> *Comment=
 # 53 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c53> on
> bug 94990 <https://bugs.freedesktop.org/show_bug.c=
gi?id=3D94990> from Pierre
> Moreau <pierre.morrow&=
#64;free.fr> *
>
> (In reply to Ilia Guterman from comment #52 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c52>)> i tested with 'nouveau.modeset=3D0' on k=
ernel 4.5 and 4.6 on debian/sid and got
> > the same results of screen flickering and seems like nothing insi=
de of the
> > nouveau driver getting called.
>
> Right, `nouveau.modeset=3D0` wont=E2=80=99t prev=
ent Nouveau from loading, however the
> driver is in a "disable" state and won=E2=80=99t do a thing:
> > modeset
> > Whether the driver should be enabled. 0 for disabled, 1 for enabl=
ed, 2 for headless
>
> (taken from the Nouveau wiki:https://nouve=
au.freedesktop.org/wiki/KernelModuleParameters/#modeset)
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are the assignee for the bug.
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists=
.freedesktop.org
> htt=
ps://lists.freedesktop.org/mailman/listinfo/nouveau
>
>
Created attachment 125656 [details] [review]
patch, possible fix

After some messing around i am able to boot.

I noticed it crashes only when initializing certain nvkm_gpuobj, which has =
it
'nvkm_gpuobj->size' bigger then 'nv50_instobj(memory)->mem->size &=
lt;<
NVKM_RAM_MM_SHIFT'.

catching that specific case made it better.

from your kernel directory do 'git apply
0001-nvkm_gpuobj-size-is-smaller-then-nvkm_gpuobj-size-ca.patch

and if you can post the boot log.
So, I just install fresh Fedora 24 with kernel-4.5.5, then rem=
ove nouveau from
system completely:

1. # echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.=
conf

2. Paste =E2=80=98rd.driver.blacklist=3Dnouveau=E2=80=99 to end of =E2=80=
=98GRUB_CMDLINE_LINUX=3D=E2=80=9D=E2=80=A6=E2=80=9D  in
/etc/sysconfig/grub

3. # grub2-mkconfig -o /boot/grub2/grub.cfg

4. # dnf remove xorg-x11-drv-nouveau

5. # dracut /boot/initramfs-$(uname -r).img $(uname -r)

After this steps reboot, upgrade system to kernel-4.6.5, and install nVidia
proprietary driver. Everything works just fine.
(In reply to Ilia Guterman from comment #55)
> Created attachment 125656 [details] [review]=
 [review]
> 0001-nvkm_gpuobj-size-is-smaller-then-nvkm_gpuobj-size-ca.patch
>=20
> After some messing around i am able to boot.
>=20
> I noticed it crashes only when initializing certain nvkm_gpuobj, which=
 has
> it 'nvkm_gpuobj->size' bigger then 'nv50_instobj(memory)->mem-&g=
t;size <<
> NVKM_RAM_MM_SHIFT'.
>=20
> catching that specific case made it better.
>=20
> from your kernel directory do 'git apply
> 0001-nvkm_gpuobj-size-is-smaller-then-nvkm_gpuobj-size-ca.patch
>=20
> and if you can post the boot log.

Hi Ilia,

I applied your patch and my system now boots up. I saw an login-screen-image
from before the boot for a split-second.  apart from that, it seems to run
fine. (no stress testing done, just firefox and some gnome terminals...)

what does your patch do? increase the reported size of some of the objects?=

Created attachment 125833 [details]
dmesg with patch 125656 applied. everything else fedora stock...
It increases the size of nv50_instobj objects that report the =
size of 0x3000.

Struct "nv50_instobj" has size of 0x3000 but it's parent structure
"nvkm_gpuobj" reports different size, a size of 0x97000.

All the other instances of nvkm_gpuobj and their child nv50_instobj report
similar size size to each other so they are fine.

It is a mystery to me why the sizes doesn't match, because if I understand
correctly the sizes are reported by the GPU itself.
If I try to start redeclipse, it segfaults. :(
(In reply to Ivan from comment #56)
> So, I just install fresh Fedora 24 with kernel-4=
.5.5, then remove nouveau
> from system completely:
>=20
> [=E2=80=A6]
>=20
> After this steps reboot, upgrade system to kernel-4.6.5, and install n=
Vidia
> proprietary driver. Everything works just fine.

Which is a nice work around if one wishes to go with the plethora of proble=
ms
nVidia drives give you=E2=80=A6
(In reply to Ivan from comment #56)
> So, I just install fresh Fedora 24 with kernel-4.5.5, then remov=
e nouveau
> from system completely:
>=20
> [=E2=80=A6]
>=20
> After this steps reboot, upgrade system to kernel-4.6.5, and install n=
Vidia
> proprietary driver. Everything works just fine.

Which is a nice work around if one wishes to go with the plethora of proble=
ms
nVidia drives give you=E2=80=A6
What version of the non-free Nvidia driver are you using? 370.=
23 or 367.35?

On Aug 23, 2016 8:29 AM, <bugzilla-daemon@freedesktop.org> wrote:

> *Comment=
 # 61 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c61> on
> bug 94990 <https://bugs.freedesktop.org/show_bug.c=
gi?id=3D94990> from Yann
> Golanski <freedesktop=
@kierun.org> *
>
> (In reply to Ivan from comment #56 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c56>)> So, I just install fresh Fedora 24 with =
kernel-4.5.5, then remove nouveau
> > from system completely:
> >
> > [=E2=80=A6]
> >
> > After this steps reboot, upgrade system to kernel-4.6.5, and inst=
all nVidia
> > proprietary driver. Everything works just fine.
>
> Which is a nice work around if one wishes to go =
with the plethora of problems
> nVidia drives give you=E2=80=A6
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are the assignee for the bug.
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists=
.freedesktop.org
> htt=
ps://lists.freedesktop.org/mailman/listinfo/nouveau
>
>
(In reply to Efrem McCrimon from comment #62)
> What version of the non-free Nvidia driver are y=
ou using? 370.23 or 367.35?

I do not use the non-free Nvidia driver because it causes many more problems
than it solves: every kernel upgrade might break things until a new driver =
is
released. At least with the nouveau, it's more in sync.  Well, this bug none
withstanding :)
(In reply to Efrem McCrimon from comment #62)
> What version of the non-free Nvidia driver are =
you using? 370.23 or 367.35?

I do not use the non-free Nvidia driver because it causes many more problem=
s
than it solves: every kernel upgrade might break things until a new driver =
is
released. At least with the nouveau, it's more in sync.  Well, this bug=
 none
withstanding :)
I have to install the Nvidia driver on on development systems =
because I am
doing some programming with CUDA.  I use the CUDA Toolkit in C/C++.  I am
converting some of the software over to OpenACC.  OpenACC has it own
compilers but CUDA requires the non-free driver because the tools
communication to the driver with the APIs.

Regards,

Efrem Mc

On Wed, Aug 24, 2016 at 4:35 AM, <bugzilla-daemon@freedesktop.org> wrote:

> *Comment=
 # 63 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c63> on
> bug 94990 <https://bugs.freedesktop.org/show_bug.c=
gi?id=3D94990> from Yann
> Golanski <freedesktop=
@kierun.org> *
>
> (In reply to Efrem McCrimon from comment #62 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c62>)> What version of the non-free Nvidia driv=
er are you using? 370.23 or 367.35?
>
> I do not use the non-free Nvidia driver because =
it causes many more problems
> than it solves: every kernel upgrade might break things until a new dr=
iver is
> released. At least with the nouveau, it's more in sync.  Well, this bu=
g none
> withstanding :)
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are the assignee for the bug.
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists=
.freedesktop.org
> htt=
ps://lists.freedesktop.org/mailman/listinfo/nouveau
>
>
It is considered to be very rude to hijack a bug report for ot=
her discussions.
It is considered to be very rude to hijack a bug report for ot=
her discussions.
In reference, I do use the nouveau driver on non-CUDA developm=
ent systems.
I like how the development teams respond to bugs and fixes.  There are some
differences in the behavior of the kernels between 4.6.x and 4.7.x with the
video drivers.  I am not sure if is related to libdrm, mesa, of libGL
types.  I have a 960 GTX which is in the same product family as the 970
GTX.  Had problems with the 4.7.0 kernel and reverted back to the 4.6.5
kernel and working with some limitations.

On Wed, Aug 24, 2016 at 4:55 PM, <bugzilla-daemon@freedesktop.org> wrote:

> *Comment=
 # 65 <https://bugs.freedesktop.org/show_b=
ug.cgi?id=3D94990#c65> on
> bug 94990 <https://bugs.freedesktop.org/show_bug.c=
gi?id=3D94990> from Florian
> Mickler <florian@mic=
kler.org> *
>
> It is considered to be very rude to hijack a bug=
 report for other discussions.
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are the assignee for the bug.
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists=
.freedesktop.org
> htt=
ps://lists.freedesktop.org/mailman/listinfo/nouveau
>
>

What	Removed	Added
Assignee	nouveau@lists.freedesktop.org	gnurou@gmail.com
CC		gnurou@gmail.com

What	Removed	Added
Attachment #123172 is obsolete		1
Attachment #123173 is obsolete		1
Attachment #123174 is obsolete		1