videodevX was designed to use unadjusted system time (elapsed time since
bootup). Linux doesn't have UST, so I used the clock instead. The clock
can be adjusted, and doing so will cause problems if there is a capture
going on. That I realized. I didn't realize it would create a divide
error, though. That needs to be worked around.
I was working on a UST for Linux based on the processor cycle counter
(if the processor has one) a long time ago (2.2.x days). I'd like to
have something like that in the kernel after V4L2 goes in. Lately I am
worried about that approach to UST because some modern processors can
slow down to save power or prevent overheating, and I don't know if the
cycle counter slows down too.
Bill.
Justin Schoeman wrote:
>
> Adrian Matellanes wrote:
>
> > Dear Justin,
> > I've found what I think is a bug in videodevX.
> > I am using the latest version on a 2.4.2 kernel.
> >
> > The problem appears when I change date & time of my machine.
> > Sometimes when changing time (setting it, say, 2 hours earlier) I get a
> > crash, a divide error.
> >
> > I've been trying to fix it but, unfortunately, I cant.
> > I dont know why it arrives a value to v4l2_math_div6432 that makes the
> > division not to fit in 32 bits.
> >
> > I tried to trace the value but printk didnt allow me to check the "u32
> > d" parameter. By the way, do you know how can I trace such variables?
>
> printk("%u", i);
>
> should print a u32 value, and "%llu" a u64 value (I think).
>
> > What I know is that the value in v4l2_timestamp_divide is okay but
> > arrives corrupted at v4l2_math_div6432. Indeed I cannot even trace the
> > value once cast is done.
> >
> > I also tried to avoid the assembly code by calling directly to the
> > division, but I cannot do a 64 bit division in kernel space, when
> > loading the module it cannot find __divid3 symbol.
> >
> > I hope I explained myself clearly enough! If I can help in any way just
> > tell me.
> > Thanks very much in advance.
> >
> > Adrian
>
> bttv works on the time relative to the start of the video stream. When
> the clock gets set back, the subtraction results in an overflow, which
> results in a huge number. This then causes the problem with
> v4l2_timestamp_divide.
>
> I am not entirely sure what to do about this though, I could try make
> bttv2 guard against negative timesteps, or try to build range protection
> into videodevX...
>
> Thanks for the debugging ;-)
>
> -justin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
