From owner-freebsd-multimedia Sat Apr 19 14:28:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA13673 for multimedia-outgoing; Sat, 19 Apr 1997 14:28:23 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13660 for ; Sat, 19 Apr 1997 14:28:19 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id OAA03885; Sat, 19 Apr 1997 14:28:16 -0700 (PDT) Message-Id: <199704192128.OAA03885@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Randall Hopper cc: multimedia@freebsd.org, David Dawes Subject: Re: bt848/fxtv: More info on system freezes In-reply-to: Your message of "Sat, 19 Apr 1997 14:13:14 EDT." <19970419141314.20369@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Apr 1997 14:28:16 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We may have to file a bug report with the X server group to see if we can get them to help us out. I will be honest with you every day I use fxtv and I don't get a crash -- once I did get the font corruption and the system didn't craash however I have not been able to reproduce it. My take is that is probably more to do with the PCI chipset. The "mistery-bit" on the Bt848 is supposed to be a work around for the Natoma chipset. I still don't know what is supposed to do other than what I stated. All I am saying is that is difficult to troubleshoot on my PPRo . Guess that I will have to switch testing to my P100 which does have a Natoma chipset. You got a high praise on fxtv . Just showed the program to a friend of mine (switch between full screen and normal, use the keypad to switch channel, etc..) and my friend said : "Wow" . Regards, Amancio P.S.: To David, we are doing high speed data transfer (PCI to PCI) from the bt848 (video capture chip) to the S3's frame buffer. >From The Desk Of Randall Hopper : > 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