System hangs after some time with nouveau and GT240

[Alistair Buxton]

Upstream report:
https://bugs.freedesktop.org/show_bug.cgi?id=33165

With the Nouveau driver I get random system hangs in the Live CD - any version since it was switched to nouveau up until today's daily images. It happens after half an hour to a couple of hours usage and affects installed systems as well, until they are switched to the proprietary driver.

This is a well known bug in other trackers but I can't see it anywhere on Launchpad, so I'm reporting it and will add bug watches.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: xserver-xorg-video-nouveau 1:1.0.8-0ubuntu3
ProcVersionSignature: Ubuntu 3.11.0-4.9-generic 3.11.0-rc7
Uname: Linux 3.11.0-4-generic x86_64
ApportVersion: 2.12.1-0ubuntu2
Architecture: amd64
CasperVersion: 1.336
Date: Tue Aug 27 22:16:06 2013
LiveMediaBuild: Xubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130827)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: No upgrade log present (probably fresh install)

[s47 (shulenkov)]

In most of the modern distros by default is loading nouveau for nvidia cards. When it loading by default, it hangs completely, don`t response on all known keys (example, Alt+SysRq+B). Logs was clear with 0 bytes. Problem was solved by change card for an older nvidia 9x00 and installing proprietary driver. After changing card was all fine. Card was checked for problems with some tests, all were passed.

[Daniel Wyatt (daniel-wyatt)]

Yes, this is quite annoying.
I recall I upgraded Ubuntu and rebooted only to encounter this hang.
I can't even boot up some of the live CDs (Ubuntu, Linux Mint, ...) without bypassing nouveau.
I've switched back to the proprietary driver and everything is fine.
But we need to get to the bottom of this.

[Agent-jdh (agent-jdh)]

The nouveau driver does not appear to provide acceleration (at least for the moment) with GT240 cards. You can get X to start, however, by using

Option "NoAccel" "true"

In your X config.

It is painfully slow though, so the only real option is to use the proprietary NVidia driver.

The KMS/Nouveau framebuffer works as well, but again without acceleration, I have a copy of the dmesg output as it loads the driver and will upload if it will be useful; I guess the devs know of this issue with GT240's though.

[Jonathan (jonathan-redhat-bugs)]

Same thing happened to me on a fresh Fedora 17 install using Nouveau on a NV50 card. Not sure the precise branding on the card as it came pre-installed on a Dell Optiplex 980.

Was just running the default Fedora 17 desktop with two screens. Was mousing over on the secondary screen on a remote X11 browser window when the mouse stopped moving. After much thrashing, I was able to get it to move a little bit on screen, then nothing. I logged in to the box over ssh and tried killing the Gnome Shell, followed by the Gnome Display manager, followed by the Xorg server itself, but the screen remained frozen.

Will attach excerpt from /var/log/messages showing crash behavior and kernel dmesg at subsequent boot.

[Jonathan (jonathan-redhat-bugs)]

Created attachment 588542
/var/log/message excerpt, flush idle timeout fail and subsequent boot.

Shows a sequence of repeated vm flush timeouts, followed by kernel boot logging showing hardware configuration.

[Jonathan (jonathan-redhat-bugs)]

Finally, I was not able to get the system rebooted from the ssh terminal.. the system did not seem to respond to either reboot or sync;sync;halt. I eventually had to power cycle the box.

[Jonathan (jonathan-redhat-bugs)]

Versions:

xorg-x11-server-Xorg-1.12.0-5
xorg-x11-drv-nouveau-0.0.16-34.20110720gitb806e3f.fc17.x86_64.fc17.x86_64
libdrm-2.4.33-3.fc17.x86_64
kernel-3.3.7-1.fc17.x86_64
mesa-dri-filesystem-8.0.3-1.fc17.x86_64
mesa-dri-drivers-8.0.3-1.fc17.x86_64

[Jonathan (jonathan-redhat-bugs)]

After installing the xorg-x11-drv-nvidia packages from RPMFusion, nvidia-settings identifies the card as a 'GeForce GT 330', an OEM catch-all card name, that in this case includes 96 CUDA cores, VBIOS Version 70.15.32.00.03, 1024 MB on-board memory, 128-bit memory interface.

[Eduard Gotwig (gotwig-v)]

Still present :(

[Eduard Gotwig (gotwig-v)]

Created attachment 63234
VBIOS for NVIDIA GT ® 240

[Maarten Maathuis (madman2003)]

You might want to actually post a recent kernel log showing your problem, because the developers won't get anywhere with vague descriptions.

[Dev-gw08 (dev-gw08)]

Also following up on your mailinglist post:
there is no general problem with nouveau and nv92, which is one of the most common chipsets and works without problems for the most of us.

So you have to be more specific about what problems you do encounter in order to get real help.

[Pavel (pavel-redhat-bugs)]

I've tested nouveau driver without Gnome (xmonad only) for a long time and ot works for me.
xorg-x11-drv-nouveau-0.0.16-37.20120306gitf5d1cd2.fc17.x86_64

[Arnon (arnon-redhat-bugs)]

>rpm -q xorg-x11-drv-nouveau kernel
xorg-x11-drv-nouveau-0.0.16-37.20120306gitf5d1cd2.fc17.x86_64
kernel-3.6.1-1.fc17.x86_64
>lspci | grep VGA
04:00.0 VGA compatible controller: nVidia Corporation GT215 [GeForce GT 240] (rev a2)
>dmesg | grep NV50
[ 1.076393] [drm] nouveau 0000:04:00.0: Detected an NV50 generation card (0x0a3180a2)

Excerpt from /var/log/messages just before system hang (1st 3 lines repeated multiple times over a 1 minute period):
Oct 17 11:27:42 chyna kernel: [349047.152003] [drm] nouveau 0000:04:00.0: PGRAPH TLB flush idle timeout fail: 0x00b00003 0x00000000 0x00005068 0x00000000
Oct 17 11:27:42 chyna kernel: [349047.152003] [drm] nouveau 0000:04:00.0: vm flush timeout: engine 0
Oct 17 11:27:47 chyna kernel: [349051.215383] [drm] nouveau 0000:04:00.0: vm flush timeout: engine 5
Oct 17 11:27:47 chyna kernel: [349056.468056] [drm] nouveau 0000:04:00.0: PFIFO_INTR 0x00200000 - Ch 4

The system is hanging every few days with light usage.
I'll add dmesg output shortly. Let me know if I can provide any more useful information.

[Arnon (arnon-redhat-bugs)]

Created attachment 629132
dmesg output

[Ed (ed-redhat-bugs)]

Created attachment 646163
/var/log/messages output during boot

[Ed (ed-redhat-bugs)]

FWIW, I had to replace my previously working GT 230 card as it had died. I checked the nouveau matrix and it indicated that the G 240 should also be supported.

01:00.0 VGA compatible controller: nVidia Corporation GT215 [GeForce GT 240] (rev a2)

It would not even boot. Hanging with the Fedora Icon displayed and then going to a blank or screen splashed with noise. I've attached the output from /var/log/messages related to nouveau.

[Dwu (dwu)]

I'm trying to customize a live system based on Debian and it has encoutered the same issue with GT240 card. It seems that it works fine with other nVidia cards. But only for GT240, it simply boots and freezes when booting into X system.

If you need any logs, please let me know how to get them.

[Marcin Slusarz (marcin-slusarz)]

Please follow http://nouveau.freedesktop.org/wiki/Bugs and open new bug report.

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Fedora (fedora-redhat-bugs)]

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Arnon (arnon-redhat-bugs)]

This should not be closed as it persists in F17

[Johan (johan-redhat-bugs)]

I guess these bugs are related in F17: #743608, #810695, #830402.

[Pavel (pavel-redhat-bugs)]

Reopened against F17
I can reproduce this bug only with Gnome.

[Ed (ed-redhat-bugs)]

See also #891505 filed against F18

[Sli (sli-redhat-bugs)]

Replace hardware from Palit to another producer with same gf240 chipset solve problem for me.

[Cybjit (cybjit)]

Perhaps it would be better if the default for GT240 was noaccel? There seems to be a lot of bugs reported against it not booting.

I posted here since this is the earliest bug I found at freedesktop. I posted the details about my card in bug 41333 earlier.

I have so far found these other reports:
https://bugs.freedesktop.org/show_bug.cgi?id=41333
https://bugs.freedesktop.org/show_bug.cgi?id=43562
https://bugs.freedesktop.org/show_bug.cgi?id=50043
https://bugs.freedesktop.org/show_bug.cgi?id=52509
https://bugs.launchpad.net/ubuntu/+bug/661939
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/706063
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/574045
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/629667
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/763052
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/951331
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/993907
https://bugzilla.redhat.com/show_bug.cgi?id=704998
https://bugzilla.redhat.com/show_bug.cgi?id=753059
https://bugzilla.redhat.com/show_bug.cgi?id=891505

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Oli (oli-redhat-bugs)]

It hangs still after not much use with F18.

[Ilia Mirkin (imirkin)]

*** Bug 57211 has been marked as a duplicate of this bug. ***

[Ilia Mirkin (imirkin)]

*** Bug 49057 has been marked as a duplicate of this bug. ***

[Ilia Mirkin (imirkin)]

*** Bug 52509 has been marked as a duplicate of this bug. ***

[Ilia Mirkin (imirkin)]

*** Bug 41333 has been marked as a duplicate of this bug. ***

[Ilia Mirkin (imirkin)]

Please re-test with the latest kernel. There are reports of all nva3+ cards working fine for most people with current software.

[Andrius Štikonas (stikonas)]

I can still reproduce it with kernel 3.11 rc6. Should I run different kernel?

[Ilia Mirkin (imirkin)]

(In reply to comment #15)
> I can still reproduce it with kernel 3.11 rc6. Should I run different kernel?

That is the right kernel. Can you describe exactly what it is that you can reproduce? Logs? etc. See http://nouveau.freedesktop.org/wiki/Bugs/ for what we need.

[I know some of the bugs I marked as a dup of this one had that for old versions, but I'd still like to see updated info.]

[Andrius Štikonas (stikonas)]

Created attachment 84637
kernel_log.txt

GPU locks up when nouveau module is started with KMS enabled. It is no longer possible to start X in this case but the ttys are still usable.

[Andrius Štikonas (stikonas)]

Created attachment 84638
kernel_log_drm_debug_14.txt

Kernel log with drm.debug=14

[Ilia Mirkin (imirkin)]

Wow, so right on boot:

[ 15.639931] nouveau E[ DRM] GPU lockup - switching to software fbcon
[ 15.643599] [drm] Initialized nouveau 1.1.1 20120801 for 0000:04:00.0 on minor 0

It locks up before the probe is even done! One thing to check -- do you have any old firmware in /lib/firmware/nouveau? You shouldn't need any firmware to run nva3 (except the video firmware if you want vdpau).

Also, could you produce a log with

drm.debug=14 nouveau.debug=trace

That might provide more info as to what's going on.

[Andrius Štikonas (stikonas)]

Created attachment 84652
kernel_log_nouveau_drm_debug.txt

There is certainly no firmware in /lib/firmware/nouveau.
I've now attached a new dmesg output.

[Ilia Mirkin (imirkin)]

*** Bug 61460 has been marked as a duplicate of this bug. ***

[Ktmdms (ktmdms)]

I no longer have accel turned off but I have had to add:

        Option "ShadowFB" "1" # [<bool>]

to get mine to work.

Xorg.0.log:
[ 140.225] Current Operating System: Linux ktmtoshiba 3.11.0-0.rc6.git2.1.fc21.x86_64 #1 SMP Thu Aug 22 21:02:34 UTC 2013 x86_
64
[ 140.225] Kernel command line: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc6.git2.1.fc21.x86_64 root=UUID=895ff4c3-db90-4071-aeab-a0ec2d6b
94cf ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 ipv6.disable=1 rhgb quiet acpi_backlight=vendor acpi_osi=Linux
[ 140.225] Build Date: 30 July 2013 06:10:29AM
[ 140.225] Build ID: xorg-x11-server 1.14.2-9.fc20
[ 140.225] Current version of pixman: 0.30.0

[ 140.567] (II) Module nouveau: vendor="X.Org Foundation"
[ 140.567] compiled for 1.14.2, module version = 1.0.9
[ 140.567] Module class: X.Org Video Driver
[ 140.567] ABI class: X.Org Video Driver, version 14.1

dmesg:
[ 4.516476] fbcon: nouveaufb (fb0) is primary device
[ 6.059440] nouveau E[ DRM] GPU lockup - switching to software fbcon
[ 6.072773] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[ 6.072776] nouveau 0000:01:00.0: registered panic notifier
[ 6.072852] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 0

[Martin-peres (martin-peres)]

So, Stikonas's bug is due to PGRAPH not processing any commands .... ever.

I pushed his mmiotrace in the vbios repo for anyone willing to check what is wrong in nouveau's way of setting up pgraph.

[Alistair Buxton (a-j-buxton)]

I wonder why this bug didn't get any hardware information attached?

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1217585

[Andrius Štikonas (stikonas)]

*** Bug 52244 has been marked as a duplicate of this bug. ***

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Johan (johan-redhat-bugs)]

I just wanted to let you know that I still see this problem with F20 beta. Although now I cannot find any suspicious lines in the logs.

[Johan (johan-redhat-bugs)]

I can refine my previous comment:

There is nothing special in /var/log/messages
There is nothing special if you run journalctl as root

But if I run journalctl as my non-root user, I find a lot of lines like these at the time of the crash:

Nov 15 09:54:13 localhost.localdomain pulseaudio[2085]: [alsa-source-92HD81B1C5 Analog] asyncq.c: q overrun, queuing locally
Nov 15 09:54:13 localhost.localdomain pulseaudio[2085]: [alsa-source-92HD81B1C5 Analog] asyncq.c: q overrun, queuing locally
Nov 15 09:54:13 localhost.localdomain pulseaudio[2085]: [alsa-source-92HD81B1C5 Analog] asyncq.c: q overrun, queuing locally
Nov 15 09:54:13 localhost.localdomain pulseaudio[2085]: [alsa-source-92HD81B1C5 Analog] asyncq.c: q overrun, queuing locally
Nov 15 09:54:24 localhost.localdomain pulseaudio[2085]: [alsa-source-92HD81B1C5 Analog] ratelimit.c: 110 events suppressed

However, I guess these errors are a consequence of the hang, not the cause.

[Johan (johan-redhat-bugs)]

Could this be related to #1031946? Today I found this my journalctl, some seconds before the crash:

gnome-session[1801]: Failed to open VDPAU backend libvdpau_nouveau.so: cannot open shared object file: No such file or directory

[Johan (johan-redhat-bugs)]

#1031946 seems to be unrelated.

I had a crash again today, but now there are messages in the logs:

ov 25 14:12:11 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Nov 25 14:12:15 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
Nov 25 14:12:15 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00b00003 BUSY DISPATCH TPROP TEX MP
Nov 25 14:12:15 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000
Nov 25 14:12:15 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00005068 TEXTURE
Nov 25 14:12:15 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000
Nov 25 14:12:15 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Nov 25 14:12:15 localhost.localdomain kernel: [sched_delayed] sched: RT throttling activated
Nov 25 14:12:19 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
Nov 25 14:12:19 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00b00003 BUSY DISPATCH TPROP TEX MP
Nov 25 14:12:19 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000
Nov 25 14:12:19 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00005068 TEXTURE
Nov 25 14:12:19 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000
Nov 25 14:12:19 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Nov 25 14:12:19 localhost.localdomain systemd-logind[925]: Power key pressed.
Nov 25 14:12:23 localhost.localdomain kernel: nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail

Maybe a kernel update made the messages re-appear.

I am running kernel 3.11.9-300.fc20.x86_64.

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Johan (johan-redhat-bugs)]

I still see this issue in Fedora 20. I would like to change the version in the bug report, but I don't see how I can do this.

[penalvch (penalvch)]

Alistair Buxton, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-nouveau REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Alistair Buxton (a-j-buxton)]

This bug has been around since 2011. The nouveau developers have no idea how to fix it. Unless you can show me a commit which you believe fixes the problem I'm going to assume it is not fixed.

[Fedora (fedora-redhat-bugs)]

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Oleg-3 (oleg-3)]

Still present in 3.13.2-gentoo. I found that -EBUSY returns from nv50_fbcon_imageblit.

> what is wrong in nouveau's way of setting up pgraph.
Does it mean that the bug somewhere in nv50_grctx_generate? Just to be sure that bug in this function, is it possible to replace it using data from mmiotrace of nvidia driver? For me it is not obvious how to modificate nv50_grctx_fill in that case, what nv50_grctx_init should write to *size and, after all, may it help somehow?

[Peter (peter-redhat-bugs)]

Reopening as per comment 45.

[Ilia Mirkin (imirkin)]

Created attachment 95408
initialize stuff for gddr5 ram

This patch is based on Andrew's mmiotrace. I saw a sequence of init that I didn't see in other traces for working cards. Andrew -- would be interesting if you could check it out and see if it helps. The algorithm I came up with is insane -- there has to be some sort of data-driven thing going on there, but I couldn't work it out.

For people having issues, please do a mmiotrace of the blob loading on your card (see https://wiki.ubuntu.com/X/MMIOTracing for instructions), and send it (xz -9'd) to <email address hidden>.

[Andrius Štikonas (stikonas)]

(In reply to comment #26)
> Created attachment 95408 [details] [review]
> initialize stuff for gddr5 ram
>
> This patch is based on Andrew's mmiotrace. I saw a sequence of init that I
> didn't see in other traces for working cards. Andrew -- would be interesting
> if you could check it out and see if it helps. The algorithm I came up with
> is insane -- there has to be some sort of data-driven thing going on there,
> but I couldn't work it out.
>
> For people having issues, please do a mmiotrace of the blob loading on your
> card (see https://wiki.ubuntu.com/X/MMIOTracing for instructions), and send
> it (xz -9'd) to <email address hidden>.

I might be able to test this patch in the middle of April. Sorry, I can't access that computer now.

[Oleg-3 (oleg-3)]

For me, with this patch the problem is still present. I sent my mmiotrace (NVIDIA Corporation GT215 [GeForce GT 240]).

[Oleg-3 (oleg-3)]

Created attachment 95418
another patch for gddr5 ram

I made this patch using my mmiotrace, but it doesn't help either.

[Oleg-3 (oleg-3)]

Comment on attachment 95408
initialize stuff for gddr5 ram

Review of attachment 95408:
-----------------------------------------------------------------

::: drivers/gpu/drm/nouveau/core/subdev/fb/ramnva3.c
@@ +365,5 @@
> + /* XXX this algorithm is insane, find some sanity to it. */
> + /* [1] MMIO32 R 0x100268 0x30030200 PFB.SUBPART_CONFIG => { SELECT_MASK = 0x2 | UNK16 = 0x3 | ENABLE_MASK = 0x3 } */
> + nv_wr32(pfb, 0x10fcac, 0x00001f01);
> + for (o = 0; o < 4; o++) {
> + int off = offsets[i];

maybe int off = offsets[o]; ?

@@ +387,5 @@
> + for (i = 0x20, idx = 0; i < 0x30; i++, idx++) {
> + int pat = pattern[2 + (idx % 2)];
> + if (i == 0x26)
> + pat = 0;
> + if (i == 0x1f)

looks like this condition is always false in this for-loop

[Ilia Mirkin (imirkin)]

(In reply to comment #29)
> Created attachment 95418 [details] [review]
> another patch for gddr5 ram
>
> I made this patch using my mmiotrace, but it doesn't help either.

Oh well. Indeed the values in your mmiotrace are different, but your and Andrew's mmiotrace are the only traces I've seen that actually have the writes to those 0x10fxyz registers. (A few other traces have writes to the similar-but-different DDR3 registers.)

And yes, I definitely did want to use offsets[o] in my patch.

Well, perhaps this 0x10f stuff has nothing to do with the issue. My observation was that it seemed like for all the people it was broken for had GDDR5 ram, which is why I went in this direction.

[jwhendy (jw-hendy)]

I'm trying like crazy to figure out why I have GPU lockups, but all the bugs seem to dead end. What is the current status of this? More information, not going to fix, unconfirmed? I have an NVA3 card (Quadro FX 1800M, GT215) which cannot startx with acceleration, even with firmware.

Let me know if that's applicable to this bug and how I can provide information, if so. For reference, I'm on Arch 64bit. Trying to track down similar bugs to decide if I'm a duplicate issue or if I should start a new report.

[Jim (jim-redhat-bugs)]

I see this in 20 with KDE. System locks solid after couple of hours use.

Kernel 3.13.10-200, system fully updated.

Will try and get logs next time it happens.

[Ilia Mirkin (imirkin)]

*** Bug 77371 has been marked as a duplicate of this bug. ***

[Marco (marco-redhat-bugs)]

I have the same problem. It is a very old problem (years). When I use the open driver instead of the proprietary one, I have random frequent freezes (no more remote ssh, no more mouse; only the static last image). The only possibility is a brutal reset, resulting inconsole emergency at reboot and "fsck /home" (very danderous).

lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [GeForce GT 240] (rev a2)

uname -r
3.17.4-301.fc21.x86_64

Some input from /var/log/messages, near the freezes:

1:
Dec 9 15:23:02 localhost kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Dec 9 15:23:04 localhost kernel: nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13
Dec 9 15:23:07 localhost kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00200000, ch 6
Dec 9 15:23:08 localhost kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x04000000, ch 6
Dec 9 15:23:10 localhost kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Dec 9 15:23:12 localhost kernel: nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13
Dec 9 15:23:15 localhost kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x04000000, ch 6
Dec 9 15:23:15 localhost kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout

2:
Dec 10 07:13:51 localhost kernel: nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout

3 - an old case, on Fedora 20, from a remote console (ssh), before it lost the connection:
[ 2065.627268] nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00400000, ch 3

[Louis (louis-redhat-bugs)]

I have just updated with Fedup from Fedora 20 to Fedora 21.

Owing to a driver problem with the RPMFusion proprietary nvidia driver, I have reverted to Nouveau. Sadly this problem is **STILL** -- YEARS later -- in effect!

I have the same GT240 card. I can't work for more than about 1 hour when the PC Freezes and the logs show repeated events of:

Feb 23 05:19:02 fedora kernel: [ 2954.013518] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Feb 23 05:19:04 fedora kernel: [ 2956.011780] nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13
Feb 23 05:19:08 fedora kernel: [ 2958.011166] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
Feb 23 05:19:08 fedora kernel: [ 2958.011173] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00b00003 BUSY DISPATCH TPC_PROP TPC_TEX TPC_MP
Feb 23 05:19:08 fedora kernel: [ 2958.011182] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000
Feb 23 05:19:08 fedora kernel: [ 2958.011186] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00005068 TPC_TEX
Feb 23 05:19:08 fedora kernel: [ 2958.011190] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000
Feb 23 05:19:08 fedora kernel: [ 2960.009270] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Feb 23 05:19:10 fedora kernel: [ 2962.007477] nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13
Feb 23 05:19:14 fedora kernel: [ 2964.005890] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
Feb 23 05:19:14 fedora kernel: [ 2964.005895] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00b00003 BUSY DISPATCH TPC_PROP TPC_TEX TPC_MP
Feb 23 05:19:14 fedora kernel: [ 2964.005899] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000
Feb 23 05:19:14 fedora kernel: [ 2964.005901] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00005068 TPC_TEX
Feb 23 05:19:14 fedora kernel: [ 2964.005904] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000
Feb 23 05:19:14 fedora kernel: [ 2966.003981] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Feb 23 05:19:16 fedora kernel: [ 2968.002156] nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13
Feb 23 05:19:20 fedora kernel: [ 2970.000542] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
Feb 23 05:19:20 fedora kernel: [ 2970.000546] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x00b00003 BUSY DISPATCH TPC_PROP TPC_TEX TPC_MP
Feb 23 05:19:20 fedora kernel: [ 2970.000550] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000
Feb 23 05:19:20 fedora kernel: [ 2970.000553] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00005068 TPC_TEX
Feb 23 05:19:20 fedora kernel: [ 2970.000555] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00000000

until it the below happens, and the PC reboots on its own:

Feb 23 05:19:38 fedora kernel: [ 2989.982609] nouveau E[ PGRAPH][0000:01:00.0] vm flush timeout
Feb 23 05:19:40 fedora kernel: [ 2991.980777] nouveau E[ VM][0000:01:00.0] vm flush timeout: engine 13
Feb 23 05:19:42 fedora kernel: [ 2992.269810] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
Feb 23 05:19:42 fedora kernel: [ 2992.365716] nouveau E[ PGRAPH][0000...

[Louis (louis-redhat-bugs)]

Further info:

kernel-3.18.7-200.fc21.x86_64
libdrm-2.4.59-4.fc21.i686
libdrm-2.4.59-4.fc21.x86_64
mesa-dri-drivers-10.4.3-1.20150124.fc21.i686
mesa-dri-drivers-10.4.3-1.20150124.fc21.x86_64
xorg-x11-drv-nouveau-1.0.11-1.fc21.x86_64

@Ben: Please would you modify the version of this BUG to Fedora 21?

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[Johan (johan-redhat-bugs)]

FYI: I still see the problem in F22.

[Matt (matt-redhat-bugs)]

I am having similar problems, and just filed
https://bugzilla.redhat.com/show_bug.cgi?id=1245875 against F22 also.

[Marco (marco-redhat-bugs)]

I have the same problem, with Fedora 23 too.
The PC have random freezes; sometimes it remain freezes, and I most force reboot with the PC button; other times the PC will restart after a few seconds of freeze.
The Nvidia GT 240 is inusable with nouveau drivers (the proprietary drivers work fine).
But proprietary legacy nvidia drivers (340xx) are no more present in Fedora 23 rpmfusion (and they old versions do not work with Fedora 23), and so I can not use Fedora 23.

[Marco (marco-redhat-bugs)]

Today I had another freeze. After a few seconds, the sistem has restarted. Then I have selected Ubuntu instead of Fedora 23 from grub menu, mounted my Fedora /var as /media/marco/var, and read the last messages in /var/log/messages (I am sure that are the last, because the next boot was the one of Ubuntu). Note that the log ends with nouveau timeout:

sudo cat /media/marco/var/log/messages | egrep "Nov 5 16:[23]" >'/home/marco/Scrivania/log'

Nov 5 16:23:04 localhost kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Nov 5 16:23:17 localhost /usr/libexec/gdm-x-session: Activating service name='org.gnome.Terminal'
Nov 5 16:23:17 localhost /usr/libexec/gdm-x-session: Successfully activated service 'org.gnome.Terminal'
Nov 5 16:23:20 localhost gnome-session: (gnome-shell:2375): Gjs-WARNING **: JS ERROR: Error: Failed to convert UTF-8 string to JS string: Sequenza di byte non valida nell'ingresso per la conversione
Nov 5 16:23:20 localhost gnome-session: AppMenuButton<._sync@resource:///org/gnome/shell/ui/panel.js:307
Nov 5 16:23:20 localhost gnome-session: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Nov 5 16:23:20 localhost gnome-session: AppMenuButton<._focusAppChanged@resource:///org/gnome/shell/ui/panel.js:267
Nov 5 16:23:20 localhost gnome-session: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Nov 5 16:23:23 localhost dbus[893]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Nov 5 16:23:23 localhost systemd: Starting Fingerprint Authentication Daemon...
Nov 5 16:23:23 localhost dbus[893]: [system] Successfully activated service 'net.reactivated.Fprint'
Nov 5 16:23:23 localhost systemd: Started Fingerprint Authentication Daemon.
Nov 5 16:23:23 localhost audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 5 16:23:23 localhost audit: USER_AUTH pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
Nov 5 16:23:23 localhost audit: USER_ACCT pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
Nov 5 16:23:23 localhost su: (to root) marco on none
Nov 5 16:23:23 localhost audit: CRED_ACQ pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
Nov 5 16:23:23 localhost audit: USER_START pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_xauth acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'...

[Marco (marco-redhat-bugs)]

Created attachment 1090462
/var/log/messages

Another freeze (often on a click of mouse - thunderbird, firefox, nemo...) at 6:52:43. Another freeze while I write this. The system reboot itself after a while. Here is /var/log/messages of today (Fedora 23; Gnome 3 not Wayland).

uname -r
4.2.5-300.fc23.x86_64

lspci -nnk | grep -iA3 vga
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT215 [GeForce GT 240] [10de:0ca3] (rev a2)
 Subsystem: CardExpert Technology Device [10b0:0401]
 Kernel driver in use: nouveau
 Kernel modules: nouveau

rpm -qa | grep xorg
xorg-x11-drv-evdev-2.9.99-2.20150807git66c997886.fc23.x86_64
xorg-x11-drv-libinput-0.14.0-2.fc23.x86_64
xorg-x11-drv-vmware-13.0.2-10.20150211git8f0cf7c.fc23.x86_64
xorg-x11-xkb-utils-7.7-15.fc23.x86_64
xorg-x11-apps-7.7-14.fc23.x86_64
xorg-x11-resutils-7.5-12.fc23.x86_64
xorg-x11-drv-wacom-0.30.0-3.fc23.x86_64
xorg-x11-fonts-ISO8859-1-75dpi-7.5-15.fc23.noarch
xorg-x11-xauth-1.0.9-4.fc23.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.5-15.fc23.noarch
xorg-x11-server-utils-7.7-17.fc23.x86_64
xorg-x11-server-Xephyr-1.18.0-0.6.20151027.fc23.x86_64
xorg-x11-drv-ati-7.6.0-0.4.20150729git5510cd6.fc23.x86_64
xorg-x11-server-Xorg-1.18.0-0.6.20151027.fc23.x86_64
xorg-x11-drv-fbdev-0.4.3-23.fc23.x86_64
xorg-x11-drv-nouveau-1.0.12-0.3.fc23.x86_64
xorg-x11-drv-vesa-2.3.2-23.fc23.x86_64
xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64
xorg-x11-fonts-Type1-7.5-15.fc23.noarch
xorg-x11-drv-openchrome-0.3.3-17.fc23.x86_64
xorg-x11-drv-vmmouse-13.1.0-2.fc23.x86_64
xorg-x11-utils-7.5-20.fc23.x86_64
xorg-x11-xtrans-devel-1.3.5-2.fc23.noarch
xorg-x11-xinit-1.3.4-10.fc23.x86_64
xorg-x11-drv-synaptics-1.8.3-1.fc23.x86_64
xorg-x11-server-common-1.18.0-0.6.20151027.fc23.x86_64
xorg-x11-font-utils-7.5-29.fc23.x86_64
xorg-x11-drv-dummy-0.3.6-24.fc23.x86_64
xorg-x11-fonts-100dpi-7.5-15.fc23.noarch
xorg-x11-xbitmaps-1.1.1-8.fc23.noarch
xorg-x11-server-Xwayland-1.18.0-0.6.20151027.fc23.x86_64
abrt-addon-xorg-2.7.0-2.fc23.x86_64
xorg-x11-proto-devel-7.7-16.fc23.noarch
xorg-x11-fonts-misc-7.5-15.fc23.noarch
xorg-x11-drv-qxl-0.1.4-6.fc23.x86_64

[Germano (germano-redhat-bugs)]

Cleaning lastest needinfo flag since it is not required

[Fedora (fedora-redhat-bugs)]

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

[James Cuzella (trinitronx)]

It appears the same crash symptoms are still happening on Ubuntu 20.04 with xserver-xorg-video-nouveau package and Nvidia GT240 chipset.

Details in Launchpad bug #1954335 - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1954335

Package version:

$ dpkg -l xserver-xorg-video-nouveau | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==========================-============-============-========================================
ii xserver-xorg-video-nouveau 1:1.0.16-1 amd64 X.Org X server -- Nouveau display driver

See linked duplicate bug #1954335 for journalctl crash logs, lspci & lshw output.