System hangs after some time with nouveau and GT240
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xserver-xorg-video-nouveau (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Upstream report:
https:/
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-
ProcVersionSign
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-
UpgradeStatus: No upgrade log present (probably fresh install)
In freedesktop.org Bugzilla #33165, Daniel Wyatt (daniel-wyatt) wrote : | #5 |
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.
In freedesktop.org Bugzilla #33165, Agent-jdh (agent-jdh) wrote : | #6 |
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.
68 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Jonathan (jonathan-redhat-bugs) wrote : | #75 |
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.
In Red Hat Bugzilla #754882, Jonathan (jonathan-redhat-bugs) wrote : | #76 |
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.
In Red Hat Bugzilla #754882, Jonathan (jonathan-redhat-bugs) wrote : | #77 |
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.
In Red Hat Bugzilla #754882, Jonathan (jonathan-redhat-bugs) wrote : | #78 |
Versions:
xorg-x11-
xorg-x11-
libdrm-
kernel-
mesa-dri-
mesa-dri-
In Red Hat Bugzilla #754882, Jonathan (jonathan-redhat-bugs) wrote : | #79 |
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.
71 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Eduard Gotwig (gotwig-v) wrote : | #7 |
Still present :(
In freedesktop.org Bugzilla #33165, Eduard Gotwig (gotwig-v) wrote : | #8 |
Created attachment 63234
VBIOS for NVIDIA GT ® 240
In freedesktop.org Bugzilla #33165, Maarten Maathuis (madman2003) wrote : | #9 |
You might want to actually post a recent kernel log showing your problem, because the developers won't get anywhere with vague descriptions.
In freedesktop.org Bugzilla #33165, Dev-gw08 (dev-gw08) wrote : | #10 |
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.
69 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Pavel (pavel-redhat-bugs) wrote : | #80 |
I've tested nouveau driver without Gnome (xmonad only) for a long time and ot works for me.
xorg-x11-
In Red Hat Bugzilla #754882, Arnon (arnon-redhat-bugs) wrote : | #81 |
>rpm -q xorg-x11-
xorg-x11-
kernel-
>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.
In Red Hat Bugzilla #754882, Arnon (arnon-redhat-bugs) wrote : | #82 |
Created attachment 629132
dmesg output
In Red Hat Bugzilla #754882, Ed (ed-redhat-bugs) wrote : | #83 |
Created attachment 646163
/var/log/messages output during boot
In Red Hat Bugzilla #754882, Ed (ed-redhat-bugs) wrote : | #84 |
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.
72 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Dwu (dwu) wrote : | #11 |
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.
In freedesktop.org Bugzilla #33165, Marcin Slusarz (marcin-slusarz) wrote : | #12 |
Please follow http://
72 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #85 |
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://
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #86 |
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.
In Red Hat Bugzilla #754882, Arnon (arnon-redhat-bugs) wrote : | #87 |
This should not be closed as it persists in F17
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #88 |
I guess these bugs are related in F17: #743608, #810695, #830402.
In Red Hat Bugzilla #754882, Pavel (pavel-redhat-bugs) wrote : | #89 |
Reopened against F17
I can reproduce this bug only with Gnome.
In Red Hat Bugzilla #754882, Ed (ed-redhat-bugs) wrote : | #90 |
See also #891505 filed against F18
In Red Hat Bugzilla #754882, Sli (sli-redhat-bugs) wrote : | #91 |
Replace hardware from Palit to another producer with same gf240 chipset solve problem for me.
77 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Cybjit (cybjit) wrote : | #13 |
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:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
78 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #92 |
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.
In Red Hat Bugzilla #754882, Oli (oli-redhat-bugs) wrote : | #93 |
It hangs still after not much use with F18.
78 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #14 |
*** Bug 57211 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #15 |
*** Bug 49057 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #16 |
*** Bug 52509 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #17 |
*** Bug 41333 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #18 |
Please re-test with the latest kernel. There are reports of all nva3+ cards working fine for most people with current software.
In freedesktop.org Bugzilla #33165, Andrius Štikonas (stikonas) wrote : | #19 |
I can still reproduce it with kernel 3.11 rc6. Should I run different kernel?
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #20 |
(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://
[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.]
In freedesktop.org Bugzilla #33165, Andrius Štikonas (stikonas) wrote : | #21 |
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.
In freedesktop.org Bugzilla #33165, Andrius Štikonas (stikonas) wrote : | #22 |
Created attachment 84638
kernel_
Kernel log with drm.debug=14
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #23 |
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/
Also, could you produce a log with
drm.debug=14 nouveau.debug=trace
That might provide more info as to what's going on.
In freedesktop.org Bugzilla #33165, Andrius Štikonas (stikonas) wrote : | #24 |
Created attachment 84652
kernel_
There is certainly no firmware in /lib/firmware/
I've now attached a new dmesg output.
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #25 |
*** Bug 61460 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #33165, Ktmdms (ktmdms) wrote : | #26 |
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-
64
[ 140.225] Kernel command line: BOOT_IMAGE=
94cf ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 ipv6.disable=1 rhgb quiet acpi_backlight=
[ 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
In freedesktop.org Bugzilla #33165, Martin-peres (martin-peres) wrote : | #27 |
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.
25 comments hidden Loading more comments | view all 114 comments |
Alistair Buxton (a-j-buxton) wrote : | #1 |
Alistair Buxton (a-j-buxton) wrote : | #2 |
I wonder why this bug didn't get any hardware information attached?
Ubuntu QA Website (ubuntuqa) wrote : | #3 |
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://
tags: | added: iso-testing |
24 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Andrius Štikonas (stikonas) wrote : | #28 |
*** Bug 52244 has been marked as a duplicate of this bug. ***
Changed in nouveau: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Launchpad Janitor (janitor) wrote : | #29 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
status: | New → Confirmed |
64 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #94 |
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.
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #95 |
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.
Nov 15 09:54:13 localhost.
Nov 15 09:54:13 localhost.
Nov 15 09:54:13 localhost.
Nov 15 09:54:24 localhost.
However, I guess these errors are a consequence of the hang, not the cause.
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #96 |
Could this be related to #1031946? Today I found this my journalctl, some seconds before the crash:
gnome-session[
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #97 |
#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.
Nov 25 14:12:15 localhost.
Nov 25 14:12:15 localhost.
Nov 25 14:12:15 localhost.
Nov 25 14:12:15 localhost.
Nov 25 14:12:15 localhost.
Nov 25 14:12:15 localhost.
Nov 25 14:12:15 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:19 localhost.
Nov 25 14:12:23 localhost.
Maybe a kernel update made the messages re-appear.
I am running kernel 3.11.9-
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #98 |
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.
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #99 |
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.
68 comments hidden Loading more comments | view all 114 comments |
penalvch (penalvch) wrote : | #30 |
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://
If it remains an issue, could you please run the following command in the development release from a Terminal (Applications-
apport-collect -p xserver-
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:/
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
importance: | Undecided → Low |
status: | Confirmed → Incomplete |
Alistair Buxton (a-j-buxton) wrote : | #31 |
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.
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
status: | Incomplete → Confirmed |
68 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #100 |
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.
67 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Oleg-3 (oleg-3) wrote : | #32 |
Still present in 3.13.2-gentoo. I found that -EBUSY returns from nv50_fbcon_
> what is wrong in nouveau's way of setting up pgraph.
Does it mean that the bug somewhere in nv50_grctx_
68 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Peter (peter-redhat-bugs) wrote : | #101 |
Reopening as per comment 45.
67 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #33 |
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:/
In freedesktop.org Bugzilla #33165, Andrius Štikonas (stikonas) wrote : | #34 |
(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:/
> 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.
In freedesktop.org Bugzilla #33165, Oleg-3 (oleg-3) wrote : | #35 |
For me, with this patch the problem is still present. I sent my mmiotrace (NVIDIA Corporation GT215 [GeForce GT 240]).
In freedesktop.org Bugzilla #33165, Oleg-3 (oleg-3) wrote : | #36 |
Created attachment 95418
another patch for gddr5 ram
I made this patch using my mmiotrace, but it doesn't help either.
In freedesktop.org Bugzilla #33165, Oleg-3 (oleg-3) wrote : | #37 |
Comment on attachment 95408
initialize stuff for gddr5 ram
Review of attachment 95408:
-------
::: drivers/
@@ +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
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #38 |
(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-
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.
In freedesktop.org Bugzilla #33165, jwhendy (jw-hendy) wrote : | #39 |
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.
62 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Jim (jim-redhat-bugs) wrote : | #102 |
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.
61 comments hidden Loading more comments | view all 114 comments |
In freedesktop.org Bugzilla #33165, Ilia Mirkin (imirkin) wrote : | #40 |
*** Bug 77371 has been marked as a duplicate of this bug. ***
62 comments hidden Loading more comments | view all 114 comments |
In Red Hat Bugzilla #754882, Marco (marco-redhat-bugs) wrote : | #103 |
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-
Some input from /var/log/messages, near the freezes:
1:
Dec 9 15:23:02 localhost kernel: nouveau E[ PGRAPH]
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][
Dec 9 15:23:08 localhost kernel: nouveau W[ PFIFO][
Dec 9 15:23:10 localhost kernel: nouveau E[ PGRAPH]
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][
Dec 9 15:23:15 localhost kernel: nouveau E[ PGRAPH]
2:
Dec 10 07:13:51 localhost kernel: nouveau E[ PGRAPH]
3 - an old case, on Fedora 20, from a remote console (ssh), before it lost the connection:
[ 2065.627268] nouveau W[ PFIFO][
In Red Hat Bugzilla #754882, Louis (louis-redhat-bugs) wrote : | #104 |
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]
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]
Feb 23 05:19:08 fedora kernel: [ 2958.011173] nouveau E[ PGRAPH]
Feb 23 05:19:08 fedora kernel: [ 2958.011182] nouveau E[ PGRAPH]
Feb 23 05:19:08 fedora kernel: [ 2958.011186] nouveau E[ PGRAPH]
Feb 23 05:19:08 fedora kernel: [ 2958.011190] nouveau E[ PGRAPH]
Feb 23 05:19:08 fedora kernel: [ 2960.009270] nouveau E[ PGRAPH]
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]
Feb 23 05:19:14 fedora kernel: [ 2964.005895] nouveau E[ PGRAPH]
Feb 23 05:19:14 fedora kernel: [ 2964.005899] nouveau E[ PGRAPH]
Feb 23 05:19:14 fedora kernel: [ 2964.005901] nouveau E[ PGRAPH]
Feb 23 05:19:14 fedora kernel: [ 2964.005904] nouveau E[ PGRAPH]
Feb 23 05:19:14 fedora kernel: [ 2966.003981] nouveau E[ PGRAPH]
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]
Feb 23 05:19:20 fedora kernel: [ 2970.000546] nouveau E[ PGRAPH]
Feb 23 05:19:20 fedora kernel: [ 2970.000550] nouveau E[ PGRAPH]
Feb 23 05:19:20 fedora kernel: [ 2970.000553] nouveau E[ PGRAPH]
Feb 23 05:19:20 fedora kernel: [ 2970.000555] nouveau E[ PGRAPH]
until it the below happens, and the PC reboots on its own:
Feb 23 05:19:38 fedora kernel: [ 2989.982609] nouveau E[ PGRAPH]
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]
Feb 23 05:19:42 fedora kernel: [ 2992.365716] nouveau E[ PGRAPH][0000...
In Red Hat Bugzilla #754882, Louis (louis-redhat-bugs) wrote : | #105 |
Further info:
kernel-
libdrm-
libdrm-
mesa-dri-
mesa-dri-
xorg-x11-
@Ben: Please would you modify the version of this BUG to Fedora 21?
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #106 |
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.
In Red Hat Bugzilla #754882, Johan (johan-redhat-bugs) wrote : | #107 |
FYI: I still see the problem in F22.
In Red Hat Bugzilla #754882, Matt (matt-redhat-bugs) wrote : | #108 |
I am having similar problems, and just filed
https:/
In Red Hat Bugzilla #754882, Marco (marco-redhat-bugs) wrote : | #109 |
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.
In Red Hat Bugzilla #754882, Marco (marco-redhat-bugs) wrote : | #110 |
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/
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/
Nov 5 16:23:17 localhost /usr/libexec/
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<
Nov 5 16:23:20 localhost gnome-session: wrapper@
Nov 5 16:23:20 localhost gnome-session: AppMenuButton<
Nov 5 16:23:20 localhost gnome-session: wrapper@
Nov 5 16:23:23 localhost dbus[893]: [system] Activating via systemd: service name='net.
Nov 5 16:23:23 localhost systemd: Starting Fingerprint Authentication Daemon...
Nov 5 16:23:23 localhost dbus[893]: [system] Successfully activated service 'net.reactivate
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_
Nov 5 16:23:23 localhost audit: USER_AUTH pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined
Nov 5 16:23:23 localhost audit: USER_ACCT pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined
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
Nov 5 16:23:23 localhost audit: USER_START pid=8132 uid=1000 auid=1000 ses=1 subj=unconfined
In Red Hat Bugzilla #754882, Marco (marco-redhat-bugs) wrote : | #111 |
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.
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-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
xorg-x11-
abrt-addon-
xorg-x11-
xorg-x11-
xorg-x11-
In Red Hat Bugzilla #754882, Germano (germano-redhat-bugs) wrote : | #112 |
Cleaning lastest needinfo flag since it is not required
In Red Hat Bugzilla #754882, Fedora (fedora-redhat-bugs) wrote : | #113 |
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.
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
status: | Confirmed → Incomplete |
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
status: | Incomplete → Confirmed |
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
status: | Confirmed → Incomplete |
Changed in xserver-xorg-video-nouveau (Fedora): | |
importance: | Unknown → High |
status: | Unknown → Won't Fix |
no longer affects: | xserver-xorg-video-nouveau (Ubuntu) |
affects: | xserver-xorg-video-nouveau (Fedora) → xserver-xorg-video-nouveau (Ubuntu) |
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
importance: | High → Undecided |
status: | Won't Fix → New |
no longer affects: | xserver-xorg-video-nouveau (Ubuntu) |
affects: | nouveau → xserver-xorg-video-nouveau (Ubuntu) |
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
importance: | Medium → Undecided |
status: | Confirmed → New |
importance: | Undecided → Medium |
status: | New → Confirmed |
description: | updated |
James Cuzella (trinitronx) wrote : | #114 |
It appears the same crash symptoms are still happening on Ubuntu 20.04 with xserver-
Details in Launchpad bug #1954335 - https:/
Package version:
$ dpkg -l xserver-
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
ii xserver-
See linked duplicate bug #1954335 for journalctl crash logs, lspci & lshw output.
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.