Bug 35965 - X freeze - Nvidia TNT 128
Summary: X freeze - Nvidia TNT 128
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-15 17:33 UTC by Sam Varshavchik
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-01 11:51:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XFree86.0.log file (35.67 KB, text/plain)
2001-04-24 21:46 UTC, Sam Varshavchik
no flags Details
Traceback (2.76 KB, text/plain)
2001-06-01 22:24 UTC, Sam Varshavchik
no flags Details
XFree86.0.log from this crash. (22.73 KB, text/plain)
2001-06-01 22:27 UTC, Sam Varshavchik
no flags Details
XF86Config-4 - dri disabled, was running in 1280x1024 (1.78 KB, text/plain)
2001-06-01 22:29 UTC, Sam Varshavchik
no flags Details

Description Sam Varshavchik 2001-04-15 17:33:54 UTC
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)

Comment 1 Sam Varshavchik 2001-04-15 17:38:10 UTC
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...

Comment 2 Mike A. Harris 2001-04-16 00:11:55 UTC
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.

Comment 3 Sam Varshavchik 2001-04-16 03:45:55 UTC
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.

Comment 4 Sam Varshavchik 2001-04-24 21:45:14 UTC
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.

Comment 5 Sam Varshavchik 2001-04-24 21:46:29 UTC
Created attachment 16305 [details]
XFree86.0.log file

Comment 6 Sam Varshavchik 2001-04-28 22:47:44 UTC
Crashed again.  Here's another core dump:


Comment 7 Mike A. Harris 2001-05-30 22:55:19 UTC
Please reconfigure your server with DRI disabled - DRI is not supported in
the NV driver.  Xconfigurator --preferxf4 --nodri

Does this solve the problem?

Comment 8 Sam Varshavchik 2001-06-01 22:24:01 UTC
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.

Comment 9 Sam Varshavchik 2001-06-01 22:24:54 UTC
Created attachment 20110 [details]

Comment 10 Sam Varshavchik 2001-06-01 22:27:45 UTC
Created attachment 20111 [details]
XFree86.0.log from this crash.

Comment 11 Sam Varshavchik 2001-06-01 22:29:06 UTC
Created attachment 20112 [details]
XF86Config-4 - dri disabled, was running in 1280x1024

Comment 12 Mike A. Harris 2001-11-01 11:51:39 UTC
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.


Comment 13 Sam Varshavchik 2001-11-01 17:34:09 UTC
I have not yet had 4.1.0 bomb out on me.  So far so good.

Note You need to log in before you can comment on or make changes to this bug.