From owner-freebsd-multimedia Sat Apr 19 11:14:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA29246 for multimedia-outgoing; Sat, 19 Apr 1997 11:14:09 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA29240 for ; Sat, 19 Apr 1997 11:14:05 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sat, 19 Apr 1997 14:13:14 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA28172; Sat, 19 Apr 97 14:13:29 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id OAA06397; Sat, 19 Apr 1997 14:13:14 -0400 Message-Id: <19970419141314.20369@ct.picker.com> Date: Sat, 19 Apr 1997 14:13:14 -0400 From: Randall Hopper To: multimedia@freebsd.org Cc: Amancio Hasty Subject: bt848/fxtv: More info on system freezes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I beat on the system freeze problem this morning, and whittled it down to a very simple procedure that always quickly reproduces the problem on my system. First, how to reproduce it, followed by my system configuration: HOW TO REPRODUCE 1) Start up X with no clients except a single stock xterm. 2) Start up fxtv 0.4 such that it doesn't overlap the xterm. fxtv is continuous displaying to the screen w/ direct video. 3) Now, start up a full-screen app (a text-mode app; runs in the xterm) 4) Lean on the key that causes the app to redraw its display After about 10-30 seconds, the xterm font gets corrupted. Shortly thereafter (milliseconds or seconds later), the X server locks up hard. Display dead, keyboard dead, mouse dead. Sometimes if I'm quick about it, I can get up off the "refresh" key in time for the queued refreshes to quit "after" the font is first corrupted but "before" the X server has locked. I can then Ctrl-Alt-Bksp to kill the server, and start it up again, giving me a sensible display with no traces of the corruption. Seems to be evidence that the X server state is being corrupted somehow, and not the system in general. Further evidence that this is typically localized to the X server and its state is that, if I have a kernel rebuild going on in an xterm and the the lock-up occurs, the kernel build will continue for 30-60 sec, presumably until the ptty device queue fills up because there's no process on the other end slirping off of it. Also of note is that after the font corruption starts, it continues to mutate some with each refresh. Line corruption through characters is the most common and stays fairly constant across refreshes, but there is some "white noise" (stray pixels) that appear and disappear in the font characters. Also, the corruption is in the colors that are used on the xterm at the time (purple, white, and blue). Seems to indicate that the font data is being corrupted before it's being blasted on the screen rather than after the fact by some corruption directly applied to the frame buffer. SYSTEM CONFIGURATION Motherboard: ASUS P55TP4XE (Triton 1), P100, 32Meg mem Video Card : STB Velocity 3D (S3988 "Virge", 4Meg VRAM) FreeBSD Ver: 2.2-GAMMA XServer Cfg: XFree 3.2A (S3V server) 1024x768 555 16bpp w/ 1152x900 desktop XTerm Cfg : stock xterm; 80x47 geometry w/ 9x15 font TV Software: Driver - bt848-970401 w/ Amancio's "missing fields" patch Client - FXTV 0.4 BIOS Cfg : I did try Steve's suggestion of: PCI Streaming = OFF; Video BIOS Cache = OFF; VGA Palette Snoop = OFF All testing done/problems encountered this morning were with these settings. Randall