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.
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, 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 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
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:  Power Management version 1
Capabilities:  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]
Crashed again. Here's another core dump:
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]
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.
I have not yet had 4.1.0 bomb out on me. So far so good.