Bug 86491

Summary: [NVE6] Nouveau crash when shutting down
Product: xorg Reporter: Jarl E. Gjessing <jarlgjessing>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: NEW --- QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: tiwai
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Image showing the screen on shutdown
none
dmesg output none

Description Jarl E. Gjessing 2014-11-20 14:50:33 UTC
Created attachment 109755 [details]
Image showing the screen on shutdown

When doing init 0, or shutdown from KDE, I end up with a kernel dump :-(
I'm unable to stop this from happening so, I cannot get into Windows either.
I tried openSUSE 13.2 just as it came out and thought that this problem was due to the live image, and therefore tried again today, using the DVD image.

Same problem :-(
Unfortunately there are no longer any /var/log/messages or the like, so I don't know what to attach.
And the guides as to where to locate these information (which I could before 13.2) is not as I see, easy to find.
I have also tried with openSUSE's HEAD version, which was a 3.18.xx version. 
Same problem

The problem arises when shutting down or sleeping.
Comment 1 Ilia Mirkin 2014-11-20 14:58:21 UTC
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?
Comment 2 Jarl E. Gjessing 2014-11-20 15:01:56 UTC
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)
Comment 3 Ilia Mirkin 2014-11-20 15:08:18 UTC
(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".
Comment 4 Jarl E. Gjessing 2014-11-20 15:09:07 UTC
Created attachment 109758 [details]
dmesg output
Comment 5 Takashi Iwai 2014-11-20 15:24:57 UTC
(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.
Comment 6 Ilia Mirkin 2014-11-20 15:37:47 UTC
[   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.)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.