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

Wed Apr 12 20:38:33 UTC 2006

On Thursday 06 April 2006 19:59, Robert Krten wrote:
> 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.

Tuning takes time, presumably much longer than activating (and deactivating) 
capture. Also, depending on the design the time it takes to tune is likely 
dependent on from which frequency region to which frequency region it goes 
(IIRC one for mainly FM and perhaps antenna, one for "mid" TV freqs, one for 
high).

> > > 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...

I've used bktr a bit for testing purposes (with one card) a few weeks ago on a 
new AMD64 box but had trouble with stability of the box itself. I have no 
reason to think that this had to do with bktr, rather the combination of 
hardware (it would sometimes just shut off). Haven;t gotten around to trying 
with a more recent 6.x yet.

> > 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.

Well, the original meteor capture boards didn't have a tuner, so there you go. 
Tuning is mostly an extension to the meteor capturing stuff in bktr.

> 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?

You may wanna look at how camserve does it (it's in ports). I haven't looked 
at its code myself, but it produces single images.

> > > 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.

[copied in:]

> I've been playing with it for a few days now, and found that after tuning,
> I put in a 50ms delay and everything is fine.  CAP_SINGLE gives me a clean
> image.
>
> > > 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?
> >
> > I'm pretty sure the ringbuffer is not actually usable.  if you figure
> > out how to use it, please let me know!

> I tried to check out the OpenBSD version of the source that you pointed
> me to, but alas some helpful individual(s) made copious gratuitous source
> changes in the Open and/or Free source tree.  Thus there were 3500+ lines
> of source code changes to wade through (even with various diff options).

Yeah mostly in Free's bktr. Not everything for the better IMHO.

>
> I gave up :-(
>
> However, I did "fix" (more accurately, "work around") the problems
> that I had -- capturing with YUV_PLANAR mode does not crash my system,
> so I am now happy and consider the problem "solved" (until I get to
> the next crash) :-)
>

YUV_PLANAR, maybe also PACKED are "native" to the hardware (and produce nicer 
images). So, yeah, it sounds like RGB ticks something off on your system, I 
do know that 32 bits RGB is a bit of kludge (its actually 24) in bktr, and 
maybe this isnt well taken on your amd64 box. Does fxtv run (with rgb)?

HTH,

Dan

>
> 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!
> _______________________________________________
> freebsd-multimedia at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
> To unsubscribe, send any mail to
> "freebsd-multimedia-unsubscribe at freebsd.org"