From owner-freebsd-multimedia Sat Mar 1 17:53:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA12817 for multimedia-outgoing; Sat, 1 Mar 1997 17:53:09 -0800 (PST) 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 RAA12810 for ; Sat, 1 Mar 1997 17:53:06 -0800 (PST) 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 RAA00410 for ; Sat, 1 Mar 1997 17:53:04 -0800 (PST) Message-Id: <199703020153.RAA00410@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 cc: multimedia@freebsd.org Subject: Re: to anyone with the bt848 databook... In-reply-to: Your message of "Sat, 01 Mar 1997 16:34:11 PST." <199703020034.QAA00389@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Mar 1997 17:53:04 -0800 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thomas Arnold fax the needed pages and I think that I managed to fix the bug which Randall Hopper I thank both Thomas and Randall!! This is part of Randall's bug report: ---- A few small problems to report with the driver to report (nothing hangs the system -- just some strange behavior). BTW this is with the 0.3 driver. Here are some canned samples to demonstrate what I'm seeing. 1. To reproduce the first one, in the dtv event loop, add: sleep(1); i = METEOR_CAP_STOP_CONT; ioctl(video, METEORCAPTUR, &i); i = METEOR_CAP_CONTINOUS; /* now cruise */ ioctl(video, METEORCAPTUR, &i); --- What this bug report actually translates to is the lack of a proper error recovery condition on the driver. If upon interrupt , the status register (0x100) has bit 12 set , then restart the capture process. bit12 is set when a pixel data FIFO overrun condition is being handled by dropping as many DWORDs as needed, indicating bus access latencies are long. The bug resolution was simply arrived by printing the status register at the start of the interrupt routing and comparing a known good run of "dtv" against a run which "dtv" was having problems with the capture process. In this case "dtv" was just simply stopping or pausing for a few seconds. More aggressive testing so I may release another version of the driver tonite. Enjoy, Amancio >From The Desk Of Amancio Hasty : > > Can someone please email me or fax me the pages that deal with INT_STAT > or register 0x100? > > Left my databook at work which is over 600 miles away :( > > Tnks, > Amancio > > >