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

Jacob Meuser jakemsr at jakemsr.com
Thu Apr 6 09:51:02 UTC 2006


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 :(

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

-- 
<jakemsr at jakemsr.com>




More information about the freebsd-multimedia mailing list