Red Hat Bugzilla – Bug 35965
X freeze - Nvidia TNT 128
Last modified: 2007-04-18 12:32:40 EDT
This is the first time I recall getting a hard freeze on this relatively old, and tested card. seawolf XFree86-4.0.3-5 In the middle of typing, the display stopped responding. xclock no longer updated. The pointer continued to follow the mouse. No response to mouse buttons. No response to keyboard activity. No response to CTRL-ALT-F[17], could not switch terminals. I was able to succesfully ssh to this machine over the network, and determine that the system was running just fine. There was no load, the X process was idling, strace showed X in a middle of a select(), idling. I as able to easily kill X. gdm restarted it, and I was able to log back in, and resume working. CTRL-ALT-F[17] worked again. Too lake now, I forgot to check if X was receiving any input. Asus P2B-DS motherboard, dual PII-400, 256MB RAM, 520MB swap. 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) Flags: bus master, medium devsel, latency 64 Memory at e4000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: e1000000-e2dfffff Prefetchable memory behind bridge: e2f00000-e3ffffff 00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 32 I/O ports at d800 [size=16] 00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d400 [size=32] 00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890 Subsystem: Adaptec 2940U2W SCSI Controller Flags: bus master, medium devsel, latency 32, IRQ 9 BIST result: 00 I/O ports at d000 [size=256] Memory at e0800000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [dc] Power Management version 1 :0b.0 Ethernet controller: Winbond Electronics Corp W89C940 Flags: medium devsel, IRQ 10 I/O ports at b800 [size=32] Expansion ROM at <unassigned> [disabled] [size=32K] 01:00.0 VGA compatible controller: nVidia Corporation Riva TnT 128 [NV04] (rev 04) (prog-if 00 [VGA]) Subsystem: Creative Labs Graphics Blaster CT6710 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at e1000000 (32-bit, non-prefetchable) [size=16M] Memory at e3000000 (32-bit, prefetchable) [size=16M] Expansion ROM at e2ff0000 [disabled] [size=64K] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 1.0 00:00.0 Class 0600: 8086:7190 (rev 03) 00:01.0 Class 0604: 8086:7191 (rev 03) 00:04.0 Class 0601: 8086:7110 (rev 02) 00:04.1 Class 0101: 8086:7111 (rev 01) 00:04.2 Class 0c03: 8086:7112 (rev 01) 00:04.3 Class 0680: 8086:7113 (rev 02) 00:06.0 Class 0100: 9005:001f 00:0b.0 Class 0200: 1050:0940 01:00.0 Class 0300: 10de:0020 (rev 04)
Well, now that I think about it, X *should*'ve been getting constant input, from xclock. All I saw was X sitting in a select() call, and not getting anything...
Can you reproduce this behaviour at will? If so, please describe the exact steps to follow to reproduce this problem, what all software you are running, GNOME applets, etc.. (or KDE, etc..). Please create a file attachment of your X server logs as well. Particularly one from after a crash. You will likely need to grab the log from a ssh session if using gdm, because if you log back into X it will overwrite your old log with a new one.
It's not reproducible - it locked up after being up continuously for about ~72 hours. I have two machines with the same TNT card up and running. I'll grab the log if and when I get another lockup.
It blew up on me again. I came back to the machine after it was sitting idle for about six hours. The display was frozen in a middle of a screen saver, the machine did not respond to mouse or keyboard activity, nor CTRL-ALT-Fx. Logging into the box over the network revealed the fact that X wasn't running at all. It dumped core on me. After X crashed on me for the first time a week ago, I began booting in run level 4, then manually running startx. So, I checked, and there was a nice 37 MB core dump sitting in my home directory. Loading the core dump into gdb confirmed that it came out of X. I am attaching the XFree86.0.log file, which I saved. The timestamp on the XFree86.0.log file was about 15 minutes before the timestamp on the core dump file. Here is the core dump: http://www.email-scan.com/core.gz The gzipped file is about 4 megs, uncompressed it's about 37 megs, and it's against the server in XFree86-4.0.3-5 package.
Created attachment 16305 [details] XFree86.0.log file
Crashed again. Here's another core dump: http://www.email-scan.com/core2.gz
Please reconfigure your server with DRI disabled - DRI is not supported in the NV driver. Xconfigurator --preferxf4 --nodri Does this solve the problem?
Nope! Just had another crash. I'm seeing this on two machines with the same TNT 128 card. It looks like the following traceback indicates heap corruption. I have the core file, but I doubt that it would contain anything useful.
Created attachment 20110 [details] Traceback
Created attachment 20111 [details] XFree86.0.log from this crash.
Created attachment 20112 [details] XF86Config-4 - dri disabled, was running in 1280x1024
Can you update the report and let me know if this problem is still present in XFree86 4.1.0 as shipped with Red Hat Linux 7.2? If it is still present, attach any new information you may have, and I will send it upstream to Nvidia directly. Thanks.
I have not yet had 4.1.0 bomb out on me. So far so good.