Created attachment 428756 [details] /var/log/Xorg.0.log.old after power cycle and reboot. Note the line "Segmentation fault). Server aborting" Description of problem: Various operations cause the box to freeze up, requiring a power cycle. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64 How reproducible: very! Steps to Reproduce: 1. boot and log in 2. attempt to display a jpg with 'xv' 3. or, start xosview Actual results: Screen freezes, not even cursor motion. No window has focus, no keyboard input is effective, cannot bring up a text login, etc. Have to power cycle. Expected results: Image should be viewable, or xosview should come up. I believe I could find several other ways to tickle this bug if it really mattered. Additional info: After power cycle, /var/log/Xorg.0.log.old ends with mention of a segmentation fault. File is attached. This is a fully-up-to-date Fedora 13. Well, the xv and xosview are f12 since newer ones don't seem to exist. Also the balsa and gthumb are f12 because the f13 ones crashed the first time I ran them, but I don't (yet) have reason to connect those crashes to this current bug.
I have been running F13 on this box for weeks, the symptom began yesterday. So either some yum update did bad things, or else I stumbled over a way to poison my system. For example, I ran xosview-1.8.3-17.20080301cvs.fc12.x86_64 every day, and suddenly I don't dare: it gets half rendered and we freeze up. If there's a way to un-poison the system I'd love to know it. --- Don
/var/log/yum.log shows that my f13 box went from xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64 to xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64 on 29 July, which is suspicious timing. So I did "yum downgrade xorg-x11-drv-nouveau", which for some reason leaves me at a third rev level, xorg-x11-drv-nouveau-0.0.16-3.20100305git6b8b157.fc13.x86_64 After an X restart, the symptom appears to be gone. So I believe the transition from -6 to -7 introduced the issue. --- Don
I can't reproduce the problem here for some reason: xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64 xorg-x11-server-Xorg-1.8.0-17.fc13.x86_64 xv-3.10a.jumbopatch.20070520-10.fc12.x86_64 libdrm-2.4.20-1.fc13.x86_64 libdrm-2.4.20-1.fc13.i686 xosview-1.8.3-17.20080301cvs.fc12.x86_64
I can temporarily reinstall the -7 nouveau, if you can suggest what kind of measurement I can make that would be useful. You already have a segfault traceback, I assume another one has no value? I could try xosview under strace under 'script -f', any better idea ? --- Don
The odd part is that I don't see it here too, I *should* as the card I'm using will hit the same driver paths as you. I'll try on some other systems today however.
My new firefox displays the new Google Image Search with horrible artifacts (I will upload a screenshot in moments). So I upgraded to the latest nouveau, xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64, to see if it fixed that. It did. Unfortunately, the seg fault bug then bricked my machine, so I power cycled and ran "yum downgrade" again. I have a new Xorg.0.log.old which I will upload in moments, again ending with a Segmentation Fault traceback. --- Don
Created attachment 434114 [details] another Xorg log showing signal 11 Again, I ran xosview-1.8.3-17.20080301cvs.fc12.x86_64 and xv-3.10a.jumbopatch.20070520-10.fc12.x86_64 and it bricked after some seconds.
Created attachment 434115 [details] screenshot of visual artifacts with the downgraded driver. You seem to have fixed these in the -7 release, so I'm just including it here for completeness. But it's much easier to live with occasional artifacts than power cycles, so I'll stay downgraded for now. --- Don
I upgraded to xorg-x11-drv-nouveau-0.0.16-8.20100423git13c1043.fc13.x86_64 (to fix a gthumb issue, bug 629473). I left the machine alone for a few minutes (NOT having run xosview, NOT having run xv) and came back to see a screensaver running, When I waved the mouse, the screensaver was replaced by a normal display, which was frozen, and I had to power cycle to get out of it. I have an Xorg.0.log.old showing a seg fault, which I will upload in moments. One oddity: I had set a background image. This box has 2 displays: when it froze, the personal background image was only on one of them.
Created attachment 446431 [details] /var/messages/Xorg.0.log.old after power cycle
Created attachment 446807 [details] /var/log/Xorg.0.log.old after power cycled. Note NOT a segfault, it's EQ overflowing Screensaver,xosview,xv not implicated. I was running a gnome-game on one screen, using totem to view an mp4 on the other screen. Suddenly the video stopped changing, although its sound continued for several seconds. The cursor could still be moved around and from screen to screen, but no other action was possible. Out of sight (on other virtual desktops) was a Balsa and a Firefox. Box is a fully up to date F13, except the balsa is balsa-2.4.1-2.fc12.x86_64. Specifically, it has xorg-x11-drv-nouveau-0.0.16-8.20100423git13c1043.fc13.x86_64 Note the log message isn't a segfault. It is: EQ overflowing. The server is probably stuck in an infinite loop.
Created attachment 446813 [details] /var/log/Xorg.0.log.old after power cycle This one is a segfault, although triggered in essentially the same way as the infinite-loop reported above. Specifically, I booted a fully-up-to-date F13, ran Firefox, and then also ran xmms (xmms-1.2.11-10.20071117cvs.fc13.x86_64). When I did the click that brings up xmms's selection box, the selection box half-rendered, and the machine froze.
Created attachment 447011 [details] /var/log/Xorg.0.log.old, kernel with pcie_aspm=off. Still segfault It was suggested that I try booting with pcie_aspm=off. I wasn't sure how to do that, but what I did was: cd /boot/grub, edit grub.conf so that there was a new 'title' that did the same thing as the default (ie was followed by a root,kernel,initrd that were the same as the default). Then edited the new kernel line to kernel /vmlinuz-2.6.34.6-54.fc13.x86_64 pcie_aspm=off ro root=/dev/mapper/vg_baz-lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet When I booted and selected that, no different, still crashed when I ran xmms. (A few minutes earlier, crashed when I ran openoffice calc.)
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.