Re: VideodevX and changing time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux