Note: this bug might be a duplicate of bug 6455, they are related at the very least. Note on environment: I am using xorg 7.2-rc3 built from experimental FreeBSD ports tree (http://wiki.freebsd.org/ModularXorg/). I updated xf86-video-nv to the latest sources using git. My platform/os is FreeBSD 6.2-RELEASE-p2 amd64. Symptoms are as follows: initially X server comes up nicely, but after some time my screen completely freezes. Mouse cursor still moves, but keyboard is dead (pressing various *locks doesn't result in led lights). Except for this, system continues to work as usual - I can ssh in and do various stuff. But even if I kill X my console remains dead. (btw, I wish there was a way to revive it without reboot). I noticed that two things make the freeze much more probable. One is switching between text console and X console. The other is running "graphics intensive" application like firefox. What I mean is that if I only start xterm and don't using anything else then the freeze doesn't occur, but I didn't test this for longer than 30 minute periods. Also, sometimes freeze is preceded by some screen corruption. But not always. If I use vesa driver the everything is OK. There is no nvidia (proprietary) driver for FreeBSD amd64 at this time. BTW, the symptoms are very similar to what is described here: http://ubuntuforums.org/showthread.php?t=24703 Here's PCI description of my card (GeForce 7100 GS, 10DE:016A). Here's from lspci -v: 02:00.0 VGA compatible controller: nVidia Corporation GeForce 7100 GS (rev a1) (prog-if 00 [VGA]) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at df000000 (32-bit, non-prefetchable) Memory at c0000000 (64-bit, prefetchable) Memory at de000000 (64-bit, non-prefetchable) Expansion ROM at ddfe0000 [disabled] Capabilities: [60] Power Management version 2 Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [78] Express Endpoint IRQ 0 Here's from pciconf -lv: none4@pci2:0:0: class=0x030000 card=0x00000000 chip=0x016a10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = display subclass = VGA
Created attachment 9217 [details] xorg configuration Here's my current xorg.conf. Lines commented out with '#%#' show configuration for 'nv' driver.
Created attachment 9218 [details] xorg log with vesa driver Here's xorg start log when using vesa driver. Unfortunately I forgot to save logs for nv driver. I can not restart my X server now, so I will provide them later. Sorry.
Created attachment 9219 [details] [review] 7100 GS support patch (doesn't help much) I noticed that nv driver doesn't explicitly recognize my chip id 016A. Also i noticed that all 016X chips are assumed to be GeForce 6XXX, so I created a patch that added recognition of my card and also made it to be handled as other GeForce 7XXX cards, that is 01DX chips. Unfortunately the patch didn't help much with the freeze.
Hi Andriy, I believe the VT-switch problem and your general stability problems may be two separate issues. Does the freeze occur every time you VT-switch, or only sometimes? As for your other problem, I'll need more exact reproduction steps before I can do anything.
Created attachment 9231 [details] log file for nv driver + my 7100 GS patch
(In reply to comment #4) > Does the freeze occur every time you VT-switch, or only sometimes? it usually didn't occur on the first switch (there and back), but at most 5 switches were enough in all my attempts. > As for your other problem, I'll need more exact reproduction steps before I can do anything. I don't have a strict reproduction algorithm, but it worked like that for me: start firefox, start some random browsing (google, cnn, etc) and here you are. Usually it took less than 3 minutes to get the freeze.
According to your log file, you're using nv version 1.2.2. If you installed from git yourself, it may have installed to /usr/local/lib/xorg/modules/drivers instead of your actual module directory if you didn't use the --with-xorg-module-dir configure option.
Created attachment 9243 [details] log with the latest nv from git You are correct of course, sorry about the wrong file. Here's a log of the latest driver from git (as of this morning). It seems that VT switching problem might have been fixed to a certain degree, but I am not 100% sure: after 5 VT switches I got a screen corruption and as I was going to take to take some screenshots (I know how stupid this sounds, I should have been taking photos of my monitor) I started xv and screen was completely frozen.
Created attachment 9244 [details] log for the latest driver from git with my patch Not sure if my patch was of any help here or if it is irrelevant, but now I am almost 100% sure that VT switching problem is sufficiently fixed. What I mean is that I did a lot of VT switching and I did not get any freezes. But, I did get some screen corruptions, but those corruptions were always fixed by doing another VT switch. The corruption itself looks like some colors being substituted with others.
The other issue, complete screen freeze, is still present. The easiest way to reproduce is still doing some browsing with firefox. It also seems that scrolling web-pages (either with scroll-wheel or with a scroll-bar) triggers the freeze much sooner. Another possibly interesting fact: when after a freeze I issue system shutdown (via ssh) then at some moment the screen becomes completely black except for a rectangular area in the middle of the screen. Size of the area is about 600x300 pixels and it contains some colors and regular fine-grained patterns.
Created attachment 9245 [details] updated xorg.conf for nv driver
Comment on attachment 9219 [details] [review] 7100 GS support patch (doesn't help much) I think this patch is useless if not dangerous. I noticed that vesa driver prints something about NV44 ("VESA VBE OEM Product: nv44 Board - p280h9") and I also found some reports that 7100GS is based on NV44. So it should quite rightly be treated differently from the rest of G7XXX cards and similarly to G6XXX. The only useful part of this patch is simply a name of the card.
Please try nv 2.0.1.
Actually, never mind that, your last log should have been new enough to pick up all the relevant fixes.
I no longer own that card, so I won't be able to help with issue further. Not sure if the bug should be closed in this case.
Created attachment 12456 [details] Log of X11
Created attachment 12457 [details] xorg conf (default after installation FC8)
Created attachment 12458 [details] dmesg (hardware)
Created attachment 12459 [details] lspci list
It seems very similar bug on new release of Fedora Core 8 x86_64 with GeForce 6600GT X11 locks after about 15-40 minutes, keyboard freezes, mouse is moving, but nothing else happens. Syslog records actions after freezing - for example pressing power button to power off computer The freezing does not depend on window manager nor logged user. The freezing starts immediately when I start amarok and click list tab, and then I expand tree with radio stations. I attach 3 logs from my computer in case they would be useful. The hardware is not a reason of hanging, because on the same machine works Fedora 5 with NVidia proprietary driver for hours without freezing. Unfortunately I have no possibility to send a backtrace, or to log through ssh to my computer I tried to run "killall X" in crontab to see if X will restart after freezing, but they didn't
I'm seeing what is likely the same problem with * xorg-server 1.4, * xf86-video-nv 2.1.6, * FreeBSD 8.0-CURRENT/amd64, * GeForce 6200 LE card. Starting X11 with twm and xterms works, but as soon as I run, say, firefox, the X11 server freezes within a few seconds. It goes into a tight loop (100% CPU) and will not respond to signals. The mouse pointer moves, everything else is frozen. A workaround is to create an xorg.conf file (X -configure) and disable hardware acceleration for nv (Option "NoAccel" "true"). With this, the server will no longer freeze. This is probably the same problem as that described in later comments (like Chris Radlinski's) in bug 3168.
xf86-video-nv has been officially unmaintained for a bit now, and we are closing all -nv bugs. If your problem was not addressed, and -nv is still broken, please try xf86-video-nouveau. Thank you.
Once more, with feeling.
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.