Fishing: Any problems with bktr and amd64 v 6.0? I get page

[Robert Krten]

Jacob Meuser sez...
> 
> On Wed, Apr 05, 2006 at 10:20:32AM -0400, Robert Krten wrote:
> > 
> > I'm investigating a problem I'm having (two kernel page faults so
> > far an AMD64 on v6.0 release), possibly related to the bktr driver.
> > 
> > At this point I'm just fishing for answers, because I haven't run the new
> > system for a long time (installed Sunday).  But, when I run my
> > motion-activated recorder on two bktr devices simultaneously, the system
> > dies within minutes. If I don't run them, the system is stable.
> > 
> > I'm using Hauppauge WinTV Go + devices, if that helps, and capturing
> > frames in RGB24 mode using METEOR_CAP_SINGLE in a tight loop with a
> > tuner call to TVTUNER_SETCHNL on the associated tuner.
> > 
> > If anyone can say "Yes, that is definitely a known problem, apply patch X"
> > that would be great! :-)  Or, "Don't use METEOR_CAP_SINGLE, it's unreliable",
> > that would help too.  Even just letting me know that you use bktr on
> > an AMD64 with v6.0 and *don't* have problems would be useful...
> 
> do you actually get good results with METEOR_CAP_SINGLE?  I often
> just get gibberish.  IIRC, this is because the bt8x8 chip "needs a
> moment to settle down".  I don't recall the details, but I believe I
> read this in a comment in one of the original bktr sample programs
> which uses METEOR_CAP_SINGLE.  according to
> http://telepresence.dmem.strath.ac.uk/bt848/ the sample programs are
> at ftp://telepresence.dmem.strath.ac.uk/pub/bt848/examples
> but I can't seem to connect to that now :(

When I don't mess with the tuner, METEOR_CAP_SINGLE works just fine.
When I tune between different channels, I do sometimes (say 5-10% of the
time?) get partial frames from the previous channel.

Also, I sometimes get the wrong fields (I'm not sure of the order, but
let's say the even frame from one field and the odd frame from the next
field, which leads to interesting "jittering" effects when displayed on
an interlaced monitor).

What should I be using?  The ring-buffer one, and just fish out the samples
as I need them?  Any hints on synchronizing with tuning?

> > Otherwise, I'll be investigating the problem more this weekend.
> > 
> > On a possibly related note, a few minutes before the first crash, one of
> > my application programs (which has not crashed in 6 months) died with a
> > SIGSEGV because a pointer it was using had the value 0x888f8d847c80817f,
> > which is suspiciously "around 0x80" for every byte (I say "suspicious"
> > because that could be RGB video data.  It could be green cheese, too,
> > for all I know, but... Coincidence?)
> 
> you might want to check the OpenBSD bktr driver for 64-bit fixes,
> especially those marked, "do not use u_long for 32bit data", which
> were applied in OpenBSD close to 2 years ago and still are not in
> FreeBSD.  and there is another marked "Use proper type for 32 bit
> entity.  s/long/int/  This is needed for bktr(4) to work on sparc64."
> from 9 months ago.
> 
> http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/pci/bktr/
> 
> btw, I use bktr on OpenBSD/amd64 rather extensively, and have not seen
> any odd data corruption possibly coincidently related to bktr.

Excellent, thank you very much!

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Join us at BSDCan2006!  www.bsdcan.org for more details.
Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers!