Bug 86491

Attach a kernel log (dmesg) after boot, that should contain a lot of important info about your hardware. Also what does 'lspci -nn -d 10de:' produce?

I fully respect that not all issues are critical etc. (we all think it is in our own eyes)
But when the machines renders dead on shutdown, I think it is a critical issue?
Or at least thats just what I feel.
lspci says:
01:00.0 3D controller [0302]: NVIDIA Corporation GK106M [GeForce GTX 765M] [10de:11e2] (rev ff)

(In reply to Jarl E. Gjessing from comment #2)
> I fully respect that not all issues are critical etc. (we all think it is in
> our own eyes)
> But when the machines renders dead on shutdown, I think it is a critical
> issue?
> Or at least thats just what I feel.

Yeah, so if you have a real support organization backing a bugtracker, these things have meaning. When you have 1 or 2 people looking at bugs, markers like "critical" are more annoying than useful, amusingly enough making it _harder_ to see things since they become irregular on the giant mega-bug-list.

Having separate importance and severity markers is also incredibly confusing. In any case, at this point, this is an issue that affects just you, as far as we know, so unless your thing is literally going up in smoke, there's nothing that can be going on that makes it critical -- I think of critical as like "affects 75%+ of nouveau user base".

Created attachment 109758 [details]
dmesg output

(In reply to Ilia Mirkin from comment #3)
> (In reply to Jarl E. Gjessing from comment #2)
> > I fully respect that not all issues are critical etc. (we all think it is in
> > our own eyes)
> > But when the machines renders dead on shutdown, I think it is a critical
> > issue?
> > Or at least thats just what I feel.
> 
> Yeah, so if you have a real support organization backing a bugtracker, these
> things have meaning. When you have 1 or 2 people looking at bugs, markers
> like "critical" are more annoying than useful, amusingly enough making it
> _harder_ to see things since they become irregular on the giant
> mega-bug-list.
> 
> Having separate importance and severity markers is also incredibly
> confusing. In any case, at this point, this is an issue that affects just
> you, as far as we know, so unless your thing is literally going up in smoke,
> there's nothing that can be going on that makes it critical -- I think of
> critical as like "affects 75%+ of nouveau user base".

This is getting off-topic and a typical bikeshedding, so let's stop it :)

But here, I just give an example how these two fields work on SUSE bugzilla:
These two fiedls are seen as "priority" and "severity".  The former is the field where only developer or manager touches as the priority of the task, while the latter describes how severe the bug itself.  They can be totally decopuled; for example, in this bug, the severity can be critical as a system crashes, but its priotiy can be low as it hits only few people.

Of course, the usage of such fields pretty depends and is free for other interpretation.

[   10.538216] nouveau E[  PGRAPH][0000:01:00.0] grctx template channel unload timeout
[   10.538271] nouveau E[  PGRAPH][0000:01:00.0] failed to construct context
[   10.538273] nouveau E[  PGRAPH][0000:01:00.0] init failed, -16

This doesn't fill me with confidence...

[   33.767942] nouveau E[     DRM] failed to idle channel 0xcccc0000 [DRM]
[   36.435207] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -16

and that's not much better. What happens if you boot with

nouveau.runpm=0

Note that this will cause the secondary (nvidia) gpu to no longer auto-suspend when not in use. Oh, btw, are you using something like bumblebee? (You shouldn't be.)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/151.